fix: correct 2023-03-21 client wire contracts across the API and notify surfaces

Audits every route the March-2023 client can call against what this server
actually serves, and fixes the defects that were breaking gameplay. Adds
docs/recroom-2023-client-api-complete.md as the reference: ~500 route
literals across 13 subsystems, with verb, request/response shape, and a
per-subsystem diff. 315 defects catalogued; the ones fixed here are listed
in its "Already fixed" table.

Path coverage was never the problem — 465 of 506 routes already had
handlers. The failures were in shape, and they cluster into four causes:

- Wrong verb. The verb is a BestHTTP.HTTPMethods ordinal (GET=0 .. PATCH=5),
  confirmed from that enum's static constructor. Routes registered POST-only
  while the client PUTs returned 405, which made room consumables neither
  buyable nor consumable and blocked every room-key edit.
- Bare scalar wrapped in an object. The client reads `1000`, not
  `{"Limit":1000}`; the issuing method signature says which. Wrapping makes
  the deserializer throw and the feature dies silently.
- [FromBody] vs form-urlencoded. The client sends nearly every write as form
  data, which an [ApiController] action bound [FromBody] rejects with 415
  before the handler runs. This alone broke all 13 club member-management
  endpoints. Adds Binding/FormOrJsonModelBinder so this is fixed once.
- Notify dispatch keys. Both enum overloads of the client's RegisterHandler
  lower the id via Int32.ToString() and register only that numeric key, and
  lookup is a case-sensitive TryGetValue that returns silently on a miss. We
  were sending the enum NAME for most ids, so friend-request updates, forced
  logout, maintenance broadcasts, live balance and consumable updates, and
  invention moderation pushes all evaporated with no error anywhere.

Notable behavioural bugs fixed:

- Editing a club announcement deleted it: PUT was a third binding on the
  delete handler. Split apart, and the missing create route added.
- leaderboard/CheckAndSetStat did not exist. The 2023 client has no SetStat
  literal at all, so every leaderboard score it wrote was discarded.
- Setting a club clubhouse cleared it: the handler read roomId from the query
  while the client sends it in the body, then wrote the resulting null.
- Club join requests were inverted (the enum is Open=0, InviteOnly=1,
  AskToJoin=2), so ask-to-join clubs rejected everyone and invite-only clubs
  quietly admitted them.
- Room bans were pushed as id 24, for which the client registers no handler;
  they now go out as ModerationKick with IsBan, so the ban takes effect
  immediately instead of at next login.
- Room-key ownership queries answered for the wrong player, and "has anyone
  bought this key" asked "did I buy it" — always false for the creator.

Also persists settings that were previously acknowledged and dropped
(playlist accessibility/restrictions/level-voting/warning, per-player status
visibility, VR movement mode and avoid-juniors, custom room codes), which is
what the new columns in the migration are for.

One test asserted the old nested PriceAndCurrency response shape; the
client's consumable formatter has no such key and reads Price and
PurchaseCurrencyId flat, so the test was corrected alongside the handler.

DorkNet.Server/Controllers/API/CustomAvatarItems/CustomAvatarItemsController.cs

@@ -121,14 +121,18 @@ public class CustomAvatarItemsController(
         skip = Math.Max(0, skip);
         take = Math.Clamp(take, 1, 100);
         var currentPlayerId = this.CurrentPlayerId();
-        var rows = await db.CustomAvatarItems
+        var query = db.CustomAvatarItems
             .Where(i => i.CreatorPlayerId == creatorId
-                        && (i.IsPublic || i.CreatorPlayerId == currentPlayerId))
+                        && (i.IsPublic || i.CreatorPlayerId == currentPlayerId));
+        var total = await query.CountAsync();
+        var rows = await query
             .OrderByDescending(i => i.UpdatedAt)
             .Skip(skip)
             .Take(take)
             .ToListAsync();
-        return Ok(rows.Select(ToWire));
+        // Paged container, not a bare array — the client deserializes this into
+        // CKFLFJCNEPH {Results, TotalResults}, same as Owned() below.
+        return Ok(new { Results = rows.Select(ToWire), TotalResults = total });
     }
 
     [HttpGet("me")]
@@ -203,7 +207,11 @@ public class CustomAvatarItemsController(
         var allowed = player is not null
             && !player.IsJunior
             && (player.BannedUntil is null || player.BannedUntil <= DateTime.UtcNow);
-        return Ok(new { IsCreationAllowed = allowed, Allowed = allowed });
+        // Bare JSON boolean, like the two sibling gates below: the client's
+        // issuing method is FGLDKEJLAKB<System.Boolean> GGMDLMLJDDK()
+        // (RecNet.Runtime/MPBLNLMCEDL.txt:6048, route literal on :6205), so an
+        // object body threw and the can-create gate blocked shirt creation.
+        return Content(allowed ? "true" : "false", "application/json");
     }
 
     [HttpGet("isCreationEnabled")]
@@ -262,6 +270,13 @@ public class CustomAvatarItemsController(
         return Ok(ToWire(item));
     }
 
+    /// <summary>The 2023-03-21 client buys custom items through the
+    /// <c>econ/</c> host prefix — <c>econ/customAvatarItems/v1/{id}/purchase</c>
+    /// — which was never registered, so every custom-shirt purchase 404'd. The
+    /// rooted route below is an alias onto the same handler. <c>requestedPrice</c>
+    /// arrives as a query param and is validated against the item's real price
+    /// so a tampered client can't buy at its own number.</summary>
+    [HttpPost("/econ/customAvatarItems/v1/{id:guid}/purchase")]
     [HttpPost("{id:guid}/purchase")]
     [Authorize]
     public async Task<IActionResult> Purchase(Guid id)