The third resolver: Lobbies::invite_handle, alongside claim_seat and assign_bot. Resolves the same way plan_players' player control does (Atproto::resolve_player, a real DNS-over-HTTPS round trip), seats through the same finish_claim/Db::claim_match_player atomic write the other two resolvers use, and refuses a resolved DID already seated elsewhere the same way a self-claim's duplicate check does. The socket's request loop spawns the resolution rather than awaiting it inline - a slow lookup would otherwise block that connection from reading further messages or relaying broadcasts until it finished. The result reaches every connection the same way any other claim's does: the next seats snapshot. The happy path (a handle that actually resolves) has no test seam, same gap plan_players' own duplicate-seat guard already has and for the same reason - resolve_player holds concrete resolver fields, not a trait a fake can stand in for. What's covered without network: the fast-fail slot check ahead of the resolve call, and the write path shared verbatim with claim_seat's own tests via finish_claim. Change-Id: I9ce92de933b0ef276c668405c7704dce05d30650