fix: presence, profile edits, outfit menu and RecNetResult writes for the 2023 client

Every change below was checked against the 2023-03-21 client disassembly;
file:line evidence is in the code comments and in
docs/recroom-2023-client-api-complete.md.

Presence
- matchmake/none means "online, in no room" (its only caller is
  TryGoToOfflineRoom, which ignores the reply). The server used to keep the
  old room or invent a dorm, so the next heartbeat looked out of sync and
  the client cancelled its load to chase that room.
- The join watchdog no longer clears presence 30 s into a long room load;
  it is a 3 minute backstop that drops the room only.
- One fan-out (PresenceBroadcastService) for every transition: deferred
  joins, matchmake/none, logout, failed joins, visibility changes, SignalR
  connect/disconnect. isOnline is sent on its own; pushes never go to the
  subject, because a self push moves the player.
- Online-status visibility (Public / Friends / Favorites / Appear offline)
  is stored and honoured by GET /player and by the live pushes.

Profile
- PUT account/me/{emoji,personalpronouns,identityflags,bannerimage} were
  404; added with the client's real form keys and persisted (new Players
  columns plus migration). Every account read now returns them, and edits
  push AccountUpdate to everyone.

Outfit menu
- Saved outfits kept OutfitSelectionsV2 and CustomAvatarItems, so loading a
  slot restores what was saved instead of a stale outfit.
- isCreationAllowedForAccount answers the {Success, Error} envelope the
  client parses; minPriceForPublicItem is a bare int; gifts/generate accepts
  form bodies; lockeditems returns the full owned-item shape; colourways no
  longer share their base item's AvatarItemId.

RecNetResult writes
- About 40 writes look status-only but parse the body as {Success, Error}.
  An empty 200 showed "Failed to ..." after the server applied the change,
  and a body without Success threw "Error message cannot be null". Clubs,
  announcements, keepsakes, comments/read, subscriptions, purchase offers
  and privacy settings now answer RecNetResult.
- Login token and device-code grants are real; remoteauth approves the
  device code; createlogintoken returns a bare string.
- New: incentivizedreferrals/referrals, account/bulk/{email,phone},
  GET strings, account/me/confirmphone, PlayMenuCarouselOrdering_1.
  Route inventory and coverage test extended to match.

README now describes the 2023 branch.

DorkNet.Server/Controllers/Match/MatchController.cs

@@ -22,6 +22,7 @@ public class MatchController(
     PlayerPresenceService presence,
     PrivateInstanceService privateInstances,
     JoinTimeoutService joinTimeouts,
+    PresenceBroadcastService presenceFanout,
     RoomService rooms,
     DorkNetDbContext db,
     ILogger<MatchController> logger) : ControllerBase
@@ -67,6 +68,12 @@ public class MatchController(
                     completed.Value.TargetRoom.Name,
                     completed.Value.TargetRoom.RoomInstanceId,
                     completed.Value.DeferPresenceCommit);
+                // A deferred join (matchmake/dorm, private-instance hop)
+                // commits HERE, not at matchmake time, so this is the only
+                // point friends can learn about the move. Immediate commits
+                // were already announced by /goto.
+                if (completed.Value.DeferPresenceCommit)
+                    await presenceFanout.PublishCurrentAsync(pid);
             }
             else
             {
@@ -88,36 +95,48 @@ public class MatchController(
         return Ok();
     }
 
+    /// <summary>POST <c>matchmake/none</c> — "leave room". The 2023 client's
+    /// only caller is TryGoToOfflineRoom
+    /// (RecNet.Runtime/RecNet/Matchmaking.txt:12677-13279): it has already
+    /// switched its own cached presence to the local offline instance
+    /// (RoomInstanceId -1) before posting this, and it discards the reply
+    /// (<c>&lt;TryGoToOfflineRoom&gt;b__119_0</c> returns a constant).
+    ///
+    /// So the player is now online in no room, and that is what presence must
+    /// say. This used to re-commit the previous room (or the dorm) instead:
+    /// the next heartbeat then answered with a room while the client held the
+    /// offline instance, the client logged "presence heartbeat response
+    /// indicates local presence is out-of-sync", cancelled its offline load
+    /// ("OnPlayerPresenceUpdate is cancelling room load for -1") and chased the
+    /// server's room — and friends kept seeing the room the player had left.
+    ///
+    /// A join still pending is abandoned too: the client only goes offline
+    /// after giving up on it (fallback chain after a Photon timeout), and
+    /// echoing its target from the heartbeat would pull the player back.</summary>
     [HttpPost("/matchmake/none")]
     public async Task<IActionResult> MatchmakeNone()
     {
         var pid = this.CurrentPlayerId() ?? 0;
         if (pid == 0) return Unauthorized();
 
+        var previous = presence.GetRoom(pid);
         var pending = joinTimeouts.GetPending(pid);
-        if (pending is { DeferPresenceCommit: true })
-        {
-            presence.MarkActive(pid);
-            logger.LogInformation(
-                "[matchmake-none] player={Player} has deferred pending room={Room} instance={Instance}; not committing presence",
-                pid,
-                pending.Value.TargetRoom.RoomId,
-                pending.Value.TargetRoom.RoomInstanceId);
-            return Ok(new MatchmakingResponseDto
-            {
-                ErrorCode = 0,
-                RoomInstance = pending.Value.TargetRoom,
-            });
-        }
-
-        var current = presence.GetRoom(pid) ?? await BuildDormRoomInstanceAsync(pid);
-        presence.SetRoom(pid, current);
+        joinTimeouts.Cancel(pid, "matchmake-none");
+        presence.SetNoRoom(pid);
         presence.MarkActive(pid);
-        logger.LogInformation("[matchmake-none] player={Player}", pid);
+        presence.EndBootDormGrace(pid);
+        logger.LogInformation(
+            "[matchmake-none] player={Player} left room={Room} instance={Instance} abandonedPending={Pending}; online with no room",
+            pid, previous?.RoomId, previous?.RoomInstanceId, pending?.TargetRoom.RoomInstanceId);
+
+        await presenceFanout.PublishCurrentAsync(pid);
+
+        // The client ignores this body; keep a well-formed instance in it so
+        // the shared MatchmakingResponse reader never sees a null object.
         return Ok(new MatchmakingResponseDto
         {
             ErrorCode = 0,
-            RoomInstance = current,
+            RoomInstance = previous ?? pending?.TargetRoom ?? await BuildDormRoomInstanceAsync(pid),
         });
     }