signup codes: admin-issued invite codes + site /join redemption

While account creation is disabled, the only way in is now an
admin-issued single-use signup code (Discord-invite style), redeemed on
the public site's /join page.

Because the 2020 watch login is device-id-bound with no code field, the
flow captures it server-side instead: a new device refused at the
signups-disabled gate (PlatformLogin / account create) is stashed in a
PendingDevices table keyed by the real client IP (CF-Connecting-IP aware).
The /join page then shows the player the device their own client just
reported, they enter their code + username, and the account is minted
bound to that device — so the next launch logs straight in via the
existing device-id path. No watch changes.

- SignupCodeEntity (code, descriptor, optional expiry, redeemer) +
  PendingDeviceEntity; idempotent CREATE TABLE in DatabaseBootstrap so
  both providers pick them up without a new migration.
- SignupCodeService: generate / list / revoke / redeem + pending-device
  capture, single-use + expiry + revoke validation.
- Admin: GET/POST signup-codes + revoke endpoints and a Signup codes
  admin-ui page (generate with descriptor/expiry, status table, revoke).
- Public: anonymous /api/site/v1/join pending-devices + redeem, and a
  /join site page (+ header link).
- README documents the flow + the post-Initial table-create approach.

DorkNet.Server/Controllers/Site/PublicSiteController.cs

@@ -27,6 +27,7 @@ namespace DorkNet.Server.Controllers.Site;
 public class PublicSiteController(
     DorkNetDbContext db,
     PlayerService players,
+    SignupCodeService signupCodes,
     DomainConfig domain) : ControllerBase
 {
     // ── Players ──────────────────────────────────────────────────────
@@ -243,4 +244,41 @@ public class PublicSiteController(
             };
         }).ToList();
     }
+
+    // ── Signup (code redemption) ─────────────────────────────────────
+
+    /// <summary>GET /api/site/v1/join/pending-devices — device ids that
+    /// were refused account creation while signups are disabled, seen
+    /// from THIS caller's IP. Lets the /join page show a player the
+    /// device their own game client just reported so they don't have to
+    /// dig it out of Player.log. Best-effort: behind a proxy that
+    /// collapses client IPs this can be empty, in which case the player
+    /// pastes the id manually.</summary>
+    [HttpGet("join/pending-devices")]
+    public async Task<IActionResult> JoinPendingDevices()
+    {
+        var ip = SignupCodeService.ClientIp(HttpContext);
+        var rows = await signupCodes.RecentPendingByIpAsync(ip);
+        return Ok(rows.Select(d => new
+        {
+            deviceId = d.DeviceId,
+            platform = d.Platform,
+            lastSeenAt = d.LastSeenAt,
+        }).ToList());
+    }
+
+    public sealed record JoinRedeemRequest(string? Code, string? Username, string? DeviceId);
+
+    /// <summary>POST /api/site/v1/join/redeem — redeem a signup code,
+    /// minting an account bound to the supplied device id. On success the
+    /// player relaunches the game and the watch's device-id login finds
+    /// the new account. Returns {ok, error?, username?}.</summary>
+    [HttpPost("join/redeem")]
+    public async Task<IActionResult> JoinRedeem([FromBody] JoinRedeemRequest body)
+    {
+        var result = await signupCodes.RedeemAsync(body.Code, body.Username, body.DeviceId);
+        if (!result.Ok)
+            return BadRequest(new { ok = false, error = result.Error });
+        return Ok(new { ok = true, username = result.Username, playerId = result.PlayerId });
+    }
 }