guest sdk: large-room scale — 1024 lazy frame baselines + cross-callback roster cache

[BCook98]

Takes the guest SDK from 16-player rooms to 1024, found while load-testing large rooms (50→1000 players, 200 measured 50ms ticks per size, roguelike-shaped guest with per-player scrolling viewports).

1. rosterCap 16 → 1024, lazy per-slot baselines

The SDK silently drops Send for a roster index ≥ rosterCap — the old 16 was a hard invisible wall for any larger room. Raising it naively would cost a ~47 MiB static baseline table, so per-slot baselines (~45 KiB each) are now allocated on first commit: guest linear memory tracks the active roster, not the cap.

Identical reconciles only allocated slots; a never-sent-to slot stays not-present and recovers via its first per-player Send opening with a keyframe (unconditionally accepted) — the same recovery path as a roster change. No wire/ABI change (the send index was already u32-framed).

2. Cross-callback roster cache

The host re-sends the full member list in every callback payload, but rosters only change on join/leave/index-shift. decodeCtx now skims the member section's raw bytes (additive wire.(*Rd).SkipStr) and memcmps against the previous callback's region:

• match → the previously decoded []Player is reused, zero allocations
• mismatch → re-decode + invalidate baselines (replaces the rosterFingerprint hash; the byte compare is strictly stronger)

This matters because under -gc=leaking (the recommended profile while the TinyGo GC issue is open) the old per-callback decode leaked the roster at callback rate — measured ~100 KB/callback at 1000 players, OOMing the guest within seconds of large-room play.

Lifetime contract change: the slice from Room.Members() is valid for the duration of the callback; copy any Player you retain (long-lived state keys by AccountID, as before — no example game is affected).

Measured (Apple M4 Pro, 200 ticks/size, conservative-GC guest)

players	mean input delivery	guest leak rate (-gc=leaking)	snapshot size @1000p
before	5.4 ms @1000p	OOM at tick 17 (1000p) / 95 (500p)	7.7 MB
after	2.7 ms @1000p	OOM at tick 39 / 197 — rate halved	1.3 MB

Tick-time scaling (wake compose+send path) is unchanged by design — this PR removes the per-callback roster tax, not the render cost.

Known follow-up (out of scope here)

The remaining O(members)-per-callback cost is the payload itself: the host re-encodes and the guest re-copies the full roster bytes every callback (inputBytes() alloc — still leaked under -gc=leaking). Removing it means not resending an unchanged roster — a protocol-level change (e.g. roster epoch + on-change resend) that needs host-side coordination and an ABI design pass.

Tests

• TestRosterCache — cache hit reuses the backing slice; join/leave re-decode; first-callback semantics
• TestLazyBaselineHighSlot — slot 900: keyframe-then-delta with lazy allocation (regression guard for the silent-drop wall)
• TestIdenticalThenSendReconciles-adjacent host conformance updated separately in the engine
• full go test ./... green

🤖 Generated with Claude Code