feat(online): validate end-to-end handshake

[aram-devdocs]

Fixes #15

Summary

• validate the versioned ClientHello/ServerHello exchange, live API surface hash, capabilities, retries, restarts, and stale transport events
• bound handshake, chat, and admission work with real LiteNetLib MTU capacity, monotonic rate limiting, global new-session admission, and an atomic player-row cap
• prove client position flow, valid multi-recipient fanout, connection churn resistance, and concurrent SQLite capacity enforcement with production-path tests

Validation

• exact Windows make validate`n- .NET networking 52/52
• Rust workspace 146 passed; one intentional timed load test ignored
• protocol smoke 8/8 with real LiteNetLib client and Rust server
• spec, quality, architecture, and security review gates approved
• live in-game Phase F validation will be recorded after CI on this reviewed candidate

[aram-devdocs]

Live acceptance passed on Steam build 24324368 with PR #47 combined locally with the green startup fix in PR #44 and deployed through the isolated SailwindOnline profile.

• Continue > slot 2 reached gameplay and handshook as player 1.
• The game sent a real boat pose at (-248.1127, 0.7430, -374.5646).
• An independent LiteNetLib observer joined as player 2 at that location. It received two distinct game-client samples and reported PASS observer=2 remote=1 samples=2.
• The game log recorded the observer's inbound pose, so replication was bidirectional.
• New Game > slot 2 reached gameplay and connected at 8 ms. The reported loading hang did not reproduce.
• The server accepted both clients. No client exception or error was logged.
• Sailwind and the isolated server were closed after the test.
• All seven protected slot0*.save SHA-256 hashes matched the pre-test baseline exactly.

The exact PR head 8c889019e5d76a8ed7f9cc3a376c73530637eb85 remains green in make validate and all 13 GitHub checks.