Auth server recommendations

[nearnshaw]

This PR adds the following recommendations

1. Never derive an explicit sync id from a player address (the hash(address) % 100000 pattern). An explicit sync id creates a global network identity with a hard collision check, so it throws syncEntity failed because the id provided is already in use both across players who hash into the same slot (~50% odds by ~370 players) and when the same player reconnects before cleanup. The fix: omit the id so the SDK auto-allocates (unique by construction), and identify per-player entities by a playerId component field. Explicit enum ids stay reserved for fixed singletons — which is consistent with the existing multiplayer-sync guidance.
2. Long-running servers recycle entity slots, so a cached Map<address, Entity> can point at a dead entity, making getMutable() throw [mutable] Component ... not found every frame and dragging down whatever else runs in that system (in the PR it broke round-end handling). Fix: validate the cache with getOrNull before reuse and recreate on a stale hit; use getMutableOrNull + guard in per-frame systems so a transient miss skips one tick instead of crashing.
3. Reserved-range guard: when re-adopting entities from an engine.getEntitiesWith() scan after a server restart, skip anything with entity number (entity & 0xffff) below 512 — that's the reserved/avatar range; caching one gives a volatile handle and removeEntity() on it could delete an avatar.
4. Never use MessageBus on an auth-server scene

Where they landed:

SKILL.md:41-45 — new "Per-Player Synced Entities" subsection with the three rules in compact form.
SKILL.md:127 — new Testing & Debugging bullet mapping the two error signatures to their causes.
server-patterns.md:175-246 — full pattern with code: a getOrCreatePlayerEntity that validates its cache, a restart-reconciliation loop keyed on the playerId field with the < 512 guard and duplicate removal, and the getMutableOrNull system idiom.