feat(rust): identity — a link code from the game, and the Steam id inside core's user page

R1's identity link, site-side, and R13's first extension slot. A player types
/link in game, the plugin hands them a six-character code privately, and they
enter it here; the site records who owns which Steam account, and an operator
sees that on core's own `/admin/users/:id` page.

**The site is the author of record and the game holds nothing.** There is no
per-account store in Rust that survives a wipe, and phase 7 needs the site
authoritative anyway — it pushes permissions INTO the game keyed by Steam id. A
copy in the game would be a second thing to reconcile every wipe, for no question
it could answer better.

## D24 — a code is minted by ONE server, so every server is asked

Nothing in six characters says where it came from. The fleet is asked in turn and
the first `link.ok` wins; the others answer `unknown` and nothing happens there,
because a code is only spent at the server that actually holds it. Asking the
player to pick was rejected: a wrong pick would come back indistinguishable from
a wrong code, and that is the one refusal which must not be ambiguous.

**"Every reachable server refused" is not the same answer as "a server was
unreachable."** Collapsing them tells a player whose server is down that their
code is wrong — so they run /link again on that same server and are told the same
thing for as long as it stays down. `unsure` is that case, and it says to try
again rather than to fetch a new code.

## D23 — a Steam id another account holds is refused, never moved

The primary key is `steam_id`, and it is load-bearing rather than tidy: phase 7
grants permissions against a link and phase 13 hangs entitlements off it, so a
silent move is an account takeover performed by typing six characters. The
refusal names the holder, because the advice is unusable without it. The INSERT
is a plain INSERT for the same reason — `ON DUPLICATE KEY UPDATE` here would BE
that move — and the duplicate-key error is the refusal for the race the check
above cannot close.

The way out is `/unlink` in game, which reaches the site off the ingest feed
rather than through a route (the plugin has no link to delete). D25 adds the
other way out: staff can sever a link from the admin panel, for a player who
cannot reach that Steam account in game.

## The slot, and the hole it found in this repo's own generator

`admin.users.detail` is declared in `module.json` AND registered in `index.js`
AND filled by the chunk — three places, because the server half and the client
half are different registrations that share one name.

`swaggerFragment.js` knew only about tier routers, so the two routes under
`/admin/users/:id` were generated by nothing: a fragment that was internally
consistent and described two routes fewer than the module serves. A slot's mount
is core's and cannot be derived here, so it is a fourth constant beside
`TIER_BASE` — held to account by the frozen-manifest job, which was verified to
catch exactly this by removing the two paths and watching it fail.

## Smaller things worth knowing

- **Core's `useAsync` has no `refresh`.** A counter in the deps is how a page
  re-reads after its own write; it blanks while it re-reads, which is right here
  and is exactly what made it wrong for a poll.
- **Every player-portal nav row needs an `icon`** — core draws one on every row,
  and the client suite says so. This module had no icons file until now, because
  the public header is text buttons.
- The two new frame kinds are STAFF-only. Neither carries a code, but both name a
  Steam id beside a website account's activity, and that join is not a public
  fact about what happened on a server.
- The link code route carries its own rate limiter rather than core's
  `accountChangeLimiter`: this is guessing somebody else's secret, not changing
  your own password, and a shared counter would let one policy set the other.

Protocol 3 on all three declaration sites; 17 new tests, 136 green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMH6bw1jXMgbyF3ZWGEzSM

server/sidecarClient.js

@@ -52,18 +52,19 @@ const TIMEOUT_MS = 12000
  * here, `PROTOCOL_VERSION` in the sidecar, `ProtocolVersion` in the bridge
  * plugin, and `protocol` in its `overlay.toml`.
  *
- * **2 — the read path.** The bump lands here in the same change as the emitters,
- * even though this module does not yet consume any of the new frames: the
- * sidecar refuses a client declaring a different version with a `409`, so a
- * module left on 1 would stop being able to read the server board it has been
- * reading all along. A constant that lags the deployment is not a safe default;
- * it is an outage with a version number on it.
+ * **3 — identity.** Protocol 2 was the read path; 3 adds the first message the
+ * WEBSITE originates (`link.confirm`) and the two account frames the plugin
+ * emits beside it. The bump lands here in the same change as the emitters,
+ * because the sidecar refuses a client declaring a different version with a
+ * `409`: a module left on 2 would stop being able to read the server board it
+ * has been reading all along. A constant that lags the deployment is not a safe
+ * default; it is an outage with a version number on it.
  *
  * It is sent on every request as `X-RustLink-Version`, which turns a mismatched
  * deployment into a `409` naming both numbers instead of a parse failure three
  * layers further in.
  */
-const PROTOCOL_VERSION = 2
+const PROTOCOL_VERSION = 3
 
 /** What a caller gets back. Shaped once so every call site reads the same. */
 function reply(ok, status, data = null) {
@@ -189,6 +190,26 @@ const feed = (server, since, limit = 200) =>
 /** Where the sidecar's history currently ends. What a new server's cursor starts at. */
 const feedTail = (server) => request(server, '/feed')
 
+/**
+ * Redeem a one-time link code against one server (protocol 3).
+ *
+ * **The only call in this file that is not a GET**, and the only one that asks
+ * the game a question rather than reading what it already said. The sidecar
+ * forwards the code to the plugin, which holds the pending codes in memory, and
+ * hands back what it answers.
+ *
+ * **A refused code comes back `{ ok: true }`.** `link.ok` and `link.error` are
+ * both answers — the sidecar reserves its own failures for the transport (503
+ * when the game is down, 504 when it is up and silent) — and the caller has to
+ * tell "that code is wrong" from "the game never replied" to say the right thing
+ * to a player. So the discrimination happens on `data.kind`, not on `ok`.
+ *
+ * A code is spent on the plugin's FIRST lookup whether or not it turns out to be
+ * expired, so this must never be called speculatively for its answer alone.
+ */
+const confirmLink = (server, code) =>
+  request(server, '/link/confirm', { method: 'POST', body: { code } })
+
 module.exports = {
   TIMEOUT_MS,
   PROTOCOL_VERSION,
@@ -199,5 +220,6 @@ module.exports = {
   boards,
   feed,
   feedTail,
+  confirmLink,
   joinUrl,
 }