feat(net): Phase 4.9 — send ACK_SEQUENCE for every received server packet

Root cause of the still-purple-haze symptom AND the ACE-side
"Network Timeout" drop after ~60s. acdream was never sending
acknowledgement packets back to the server, so the server's
reliability layer saw a one-way stream and eventually dropped the
session. During the 60s window the player rendered to other clients
as the stationary purple loading haze (AC's "this client is in
portal-space transition" indicator).

Pattern ported from
references/holtburger/crates/holtburger-session/src/session/
{send.rs::send_ack, receive.rs::finalize_ordered_server_packet}.
The proper holtburger pattern is per-packet acks, NOT a periodic
heartbeat: every received server packet with sequence > 0 and no
ACK_SEQUENCE flag of its own gets a bare control packet sent back
with:

  PacketHeader {
    Flags    = ACK_SEQUENCE (0x4000),
    Sequence = current_client_sequence (= last issued, no increment),
    Id       = session client id,
  }
  Body = u32 little-endian server sequence being acked

Acks are cleartext control packets (no EncryptedChecksum) and
re-use the most recently issued client sequence rather than
consuming a new one — they aren't part of the reliable stream the
server tracks for retransmits.

Wired into ProcessDatagram so both Tick (post-InWorld) and PumpOnce
(during Connect/EnterWorld) trigger acks on every received non-ack
server packet.

Also (per user request) upgrades the CLAUDE.md description of the
holtburger reference repo from "Rust AC client crate" to "almost-
complete Rust TUI AC client — the most authoritative reference for
client-side behavior in the project, look here FIRST for anything
WorldSession or message-builder related." This was the third time
in two days I would have saved hours by checking holtburger first
instead of guessing at the protocol from ACE alone.

220 tests green.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

CLAUDE.md

@@ -164,9 +164,23 @@ these, ideally all four:
   on field order, packed-dword conventions, type-prefix handling. The
   generated Types/*.cs files have accurate field comments (e.g. "If
   it is 0, it defaults to 256*8") that ACE's server-side code doesn't.
-- **`references/holtburger/`** — Rust AC client crate. Cross-references
-  handshake quirks, race delays, and per-message encoding decisions
-  that ACE doesn't document because it's server-side.
+- **`references/holtburger/`** — **Almost-complete Rust TUI AC client.**
+  Not just a crate or a handshake reference: it's a full client that
+  logs in, plays the game, sends/receives chat, handles combat, and
+  renders state in a terminal. **This is acdream's most authoritative
+  reference for client-side behavior** — anything about how a client
+  is *supposed* to talk to the server lives here. Specifically:
+    - Handshake / login flow including all the post-EnterWorld
+      messages retail clients send (LoginComplete, ack pump,
+      DDDInterrogation responses, etc).
+    - The proper ACK_SEQUENCE pattern (every received packet with
+      sequence > 0 gets an ack queued back; not periodic).
+    - Outbound game-action message construction with sequence
+      numbering.
+    - Message routing and session lifecycle.
+  Look here FIRST when implementing anything in `WorldSession` or
+  the message-builder layer. ACE shows what the server expects;
+  holtburger shows what a real client actually sends.
 
 Pattern: when you encounter an unknown behavior, grep all four for the
 relevant term, read each hit, and compose a multi-source understanding