Versus room-limit recovery

A host could receive full while creating a new room because the account cap counted empty waiting rooms until their longer room expiry, even after all participant leases expired. The same code also represented an occupied invite, and the game then called it a general online outage. The reported incident recovered before investigation; the exact failed request was not captured. Read-only live inspection did show an empty waiting room alongside two active matches for one owner, and the new database regression reproduced the stale-reservation failure.

The owner-cap query now counts active matches and waiting rooms with a live seat. Expired empty waiting rooms retain their normal host expiry and reconnect ownership, but do not block a new room. There is no forced eviction or account-data migration. A true three-room owner limit returns room-limit; an occupied join remains full.

Validation: the new stale-seat and owner-limit assertions failed before the fix. All 20 game-control tests pass afterward, including renewed seats, active reconnects, admission, cancellation and ownership. Monorepo build and typecheck pass. The companion client maps old-server create/full responses and new room-limit responses to the same distinct recovery screen; 480 client tests pass.

The live create/join incident itself has no captured request ID, so this does not claim every transient join failure had the same cause.