docs(battlenode): document four latent low-tier hygiene hazards

Comment-only; behavior-preserving; 231 BattleNode tests green.

- OutboundSequencer._archive: name the unbounded-per-match growth + ack-prune point.
- NodeCrypto.BuildAes: SECURITY remarks on key-derived IV reuse + base64 entropy loss;
  warn against caching the session key.
- MatchContext/BattlePlayer: FOOTGUN notes on reference-based record equality over the deck list.
- RecordTokensFrom: TRUST note on isSelf/idx overwrite; name the idx>deckCount guard for
  untrusted peers (not added — trusted-LAN today).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

SVSim.BattleNode/Wire/NodeCrypto.cs

@@ -73,6 +73,16 @@ public static class NodeCrypto
     /// <paramref name="key"/> is the <see cref="KeyLength"/>-char ASCII key the encrypt /
     /// decrypt path has already validated.
     /// </summary>
+    /// <remarks>
+    /// SECURITY (latent — do NOT "tidy" this into a cached key): the IV is derived from the key, so a
+    /// fixed key reuses a fixed IV — the classic CBC IV-reuse weakness (equal plaintext prefixes →
+    /// equal ciphertext prefixes). It is masked ONLY because every server-initiated send mints a fresh
+    /// key via <see cref="GenerateKey"/>, so (key, IV) never repeats in practice. A future change that
+    /// CACHES the session key would silently reintroduce the leak — derive a per-message random IV
+    /// first. Related: <see cref="GenerateKey"/> base64-truncates a hex string, so the effective key
+    /// entropy is well below what "AES-256" implies. We mirror the client's scheme deliberately; both
+    /// are acceptable only because this is a localhost relay, not a hostile-network transport.
+    /// </remarks>
     private static Aes BuildAes(string key)
     {
         var aes = Aes.Create();