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/Services/NotificationService.cs

@@ -86,31 +86,41 @@ public class NotificationService(
     ///         concrete example: <c>GiftPackageReceived</c> registers
     ///         <c>"30"</c> and <c>GiftPackageReceivedImmediate</c>
     ///         registers <c>"31"</c>; sending the enum name misses.</item>
-    /// </list></summary>
+    /// </list>
+    ///
+    /// <para><b>The default is numeric, and that matters.</b> Both enum
+    /// overloads of the client's <c>RegisterHandler</c>
+    /// (<c>OMHPBIEHOHN.PNDNMHHDOOJ</c>) call <c>Int32.ToString()</c> on the id
+    /// and register ONLY that numeric string —
+    /// <c>RecNet.Runtime/OMHPBIEHOHN.txt:662</c> and <c>:733</c>. There is no
+    /// enum-name companion key. The dispatcher does a plain case-sensitive
+    /// <c>Dictionary.TryGetValue</c> on the envelope's <c>Id</c> and returns
+    /// silently on a miss (<c>OMHPBIEHOHN.txt:4052-4237</c>), so a wrong key is
+    /// not an error anywhere — the push simply never arrives.</para>
+    ///
+    /// <para>This used to default to <c>id.ToString()</c> (the enum NAME), which
+    /// silently dropped every enum-registered push that wasn't explicitly listed:
+    /// friend-request add/accept/remove and the RelationshipsInvalid refresh,
+    /// forced logout, maintenance broadcasts, live token-balance updates after a
+    /// level-up or purchase, consumable inventory changes, and invention
+    /// moderation state. Only the six ids below are genuinely string-keyed;
+    /// everything else must go out as a number. Verify against the binary before
+    /// adding an entry here — guessing wrong fails silently in both directions.</para>
+    /// </summary>
     private static string WireName(PushNotificationId id) => id switch
     {
-        // Custom short names — registered under a bespoke string,
-        // no integer companion in the dispatch dict.
+        // The ONLY ids registered under a bespoke string. Everything else is
+        // numeric — see the note below for why the default flipped.
+        PushNotificationId.SubscriptionUpdateProfile     => "AccountUpdate",
         PushNotificationId.SubscriptionUpdatePresence    => "PresenceUpdate",
         PushNotificationId.SubscriptionUpdateGameSession => "RoomInstanceUpdate",
-        PushNotificationId.SubscriptionUpdateProfile     => "AccountUpdate",
-        // Int-only registrations — sending the enum name misses.
-        PushNotificationId.MessageReceived               => "2",
-        PushNotificationId.MessageDeleted                => "3",
-        PushNotificationId.ModerationKick                => "22",
-        PushNotificationId.ModerationKickAttemptFailed   => "23",
-        PushNotificationId.ModerationRoomBan             => "24",
-        PushNotificationId.GiftPackageReceived           => "30",
-        PushNotificationId.GiftPackageReceivedImmediate  => "31",
-        PushNotificationId.PlayerEventCreated            => "80",
-        PushNotificationId.PlayerEventUpdated            => "81",
-        PushNotificationId.PlayerEventDeleted            => "82",
-        PushNotificationId.PlayerEventResponseChanged    => "83",
-        PushNotificationId.PlayerEventResponseDeleted    => "84",
-        PushNotificationId.PlayerEventStateChanged       => "85",
-        // Everything else: enum.ToString() matches because the watch's
-        // enum-overload RegisterHandler registers both forms.
-        _                                                => id.ToString(),
+        PushNotificationId.SubscriptionUpdateRoom        => "RoomUpdate",
+        PushNotificationId.ChatMessageReceived           => "ChatMessageReceived",
+        PushNotificationId.CommunityBoardUpdate          => "CommunityBoardUpdate",
+
+        // Numeric, because the client registered these through the enum
+        // overload. This is the default for a reason — see below.
+        _                                                => ((int)id).ToString(),
     };
 
     private static string Serialize(PushNotificationId id, object? msg) =>