feat: rate-limit connections and cap concurrent sessions (#56)

[sakebomb]

Closes #56 — the connection-rate-limiting item deferred from the security audit.

Summary

The accept loop (ServerListenerThread) spawned a RemoteSession — two threads — per connection with no limit, so a connection flood is a resource-exhaustion DoS. It also undercut the auth (#41) and setPlayer (#51) brute-force lockouts: those close only the current connection after 3 bad guesses, so an attacker just reconnected for another 3 with no cooldown.

Adds admission control on the raw socket, before a RemoteSession is built (so refused connections never spawn threads):

• max-sessions (default 100) — concurrent-session cap, reusing the existing session-list size. 0 = unlimited.
• max-connections-per-minute (default 60) — per-IP fixed-window rate limit in a new ConnectionRateLimiter (O(1), tiny memory, prunes under an IP-spoof flood). 0 = disabled.

Refused sockets are closed immediately. Defaults are classroom-friendly (100 concurrent, 60 conn/min/IP) yet close the flood and reconnect-to-brute-force loopholes.

Test plan

• ./mvnw test — 133 tests (6 new), 1 pre-existing skip
• ConnectionRateLimiterTest (4): up-to-limit-then-refuse, window reset, per-IP independence, 0-disables
• ConnectionAdmissionTest (2): session-cap boundary at the configured max, and admit() refusing the 61st connection from one IP while a different IP still passes
• Mutation-guard verified: neutering the rate check lets the over-limit connection through; weakening the session-cap < to <= flips the boundary test
• Not run against a live multi-client flood — logic covered by unit + admission tests; the live-smoke CI job still connects successfully (admit returns true on the happy path)
• config.yml, README Config, SECURITY.md, CHANGELOG updated; folds into the unreleased 2.1.0

https://claude.ai/code/session_01AcK3SgXRTVzAKBdPZw72sr