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/Leaderboard/LeaderboardController.cs

@@ -131,6 +131,106 @@ public class LeaderboardController(
         return Ok(new { success = true, error = "" });
     }
 
+    /// <summary>POST <c>/leaderboard/CheckAndSetStat</c> — the compare-and-set
+    /// form of <see cref="SetStat"/>, and the ONLY stat-write route the
+    /// 2023-03-21 client has: that build contains no <c>SetStat</c> literal at
+    /// all. Nothing registered this route, so every leaderboard score written
+    /// by a 2023 client fell through to the catch-all and was lost.
+    ///
+    /// The request is <c>RecNet.SetStatRequestDTO</c>, whose property names are
+    /// NOT obfuscated in the dump: <c>StatChannel</c> (Int32), <c>RoomId</c>
+    /// (Int64), <c>StatValue</c> (Int32) and the extra
+    /// <c>CurrentStatValue</c> (Int32?) that distinguishes this route from
+    /// plain SetStat.
+    ///
+    /// <c>CurrentStatValue</c> is the value the client believes is currently
+    /// stored. It is an optimistic-concurrency guard: the write applies only if
+    /// the server agrees, which stops a stale session from clobbering a newer
+    /// score. A null means "no expectation" and writes unconditionally, and a
+    /// mismatch is reported rather than silently dropped so the client can
+    /// re-read.
+    ///
+    /// As with SetStat, the client has already decided the new value should win
+    /// (it applies the per-channel higher/lower-is-better rule locally), so the
+    /// server does not second-guess the direction.</summary>
+    [HttpPost("/leaderboard/CheckAndSetStat")]
+    [HttpPost("/api/leaderboard/CheckAndSetStat")]
+    [Authorize]
+    public async Task<IActionResult> CheckAndSetStat([FromBody] CheckAndSetStatRequest req)
+    {
+        var pid = this.RequireCurrentPlayerId();
+        var roomId = ResolveRoomId(req.RoomId, pid);
+        var row = await db.LeaderboardStats.FirstOrDefaultAsync(s =>
+            s.RoomId == roomId && s.PlayerId == pid && s.StatChannel == req.StatChannel);
+
+        if (req.CurrentStatValue is int expected && row is not null && row.Value != expected)
+        {
+            return Ok(new
+            {
+                success = false,
+                error = "stat_value_mismatch",
+                StatValue = row.Value,
+                CurrentStatValue = row.Value,
+            });
+        }
+
+        if (row is null)
+        {
+            row = new LeaderboardStatEntity
+            {
+                PlayerId = pid,
+                RoomId = roomId,
+                StatChannel = req.StatChannel,
+                Value = req.StatValue,
+            };
+            db.LeaderboardStats.Add(row);
+        }
+        else
+        {
+            row.Value = req.StatValue;
+            row.UpdatedAt = DateTime.UtcNow;
+        }
+
+        await EnsureChannelMetaAsync(roomId, req.StatChannel);
+        await db.SaveChangesAsync();
+        return Ok(new
+        {
+            success = true,
+            error = "",
+            StatValue = row.Value,
+            CurrentStatValue = row.Value,
+        });
+    }
+
+    public sealed class CheckAndSetStatRequest
+    {
+        public int StatChannel { get; set; }
+        public long RoomId { get; set; }
+        public int StatValue { get; set; }
+
+        /// <summary>The value the client believes is stored. Null = write
+        /// unconditionally.</summary>
+        public int? CurrentStatValue { get; set; }
+    }
+
+    /// <summary>Stamp a placeholder channel-meta row the first time a channel
+    /// reports, so the admin SPA's per-room Leaderboards tab surfaces it.</summary>
+    private async Task EnsureChannelMetaAsync(long roomId, int statChannel)
+    {
+        if (roomId <= 0) return;
+        var meta = await db.LeaderboardChannelMeta
+            .FirstOrDefaultAsync(c => c.RoomId == roomId && c.Channel == statChannel);
+        if (meta is not null) return;
+        db.LeaderboardChannelMeta.Add(new LeaderboardChannelMetaEntity
+        {
+            Channel = statChannel,
+            RoomId = roomId,
+            Name = $"Channel {statChannel}",
+            LowerIsBetter = false,
+            ValueFormat = "count",
+        });
+    }
+
     public sealed class GetPlayerRankRequest
     {
         public int PlayerId { get; set; }