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

client/src/entry.jsx

@@ -20,7 +20,10 @@ import { registry, coreApiVersion } from './core.js'
 
 import Servers from './routes/public/Servers.jsx'
 import ServerDetail from './routes/public/ServerDetail.jsx'
+import Account from './routes/player/Account.jsx'
+import UserRustSections from './routes/admin/UserRustSections.jsx'
 import FooterStatus from './components/FooterStatus.jsx'
+import { IconLink } from './icons.jsx'
 
 // The module id, exactly as `module.json` spells it. Core keys the registry by it
 // and prefixes every route path with it.
@@ -54,11 +57,18 @@ const ID = 'rust'
 //
 // React Router ranks a static segment above a dynamic one, so `/rust` wins
 // against core's `/:slug` CMS route without depending on registration order.
+//
+// The player route is registered with an empty path for the same reason the
+// public list is: `/player/rust` is the whole of what this module asks a player
+// to do, and a landing page above one page is a page nobody wants. Core applies
+// its own portal chrome and its own auth gate to the tier, so the component
+// renders no layout and re-implements no check.
 registry.registerRoutes(ID, {
   public: [
     { path: '', element: <Servers /> },
     { path: 'servers/:id', element: <ServerDetail /> },
   ],
+  player: [{ path: '', element: <Account /> }],
 })
 
 // ── Nav ───────────────────────────────────────────────────────────────────
@@ -83,6 +93,18 @@ registry.registerNav(ID, {
   items: [{ label: 'Servers', to: '/rust' }],
 })
 
+// The player portal's row. It carries an `icon` because core draws one on every
+// portal row — a row without one is the only text in a column of glyphs, and
+// core used to render `<n.icon />` unguarded, which blanked the whole portal.
+//
+// No `order`: an unordered row appends after core's own rather than claiming a
+// position it was not given. Account, appeals and notifications are what a player
+// came to the portal for; linking a game account is what they do once.
+registry.registerNav(ID, {
+  area: 'player',
+  items: [{ label: 'Rust', to: '/player/rust', icon: IconLink }],
+})
+
 // ── Extension slots ───────────────────────────────────────────────────────
 //
 // Core declares a slot, only core may declare one, and at most one module may
@@ -97,6 +119,16 @@ registry.registerNav(ID, {
 // purpose.
 registry.registerExtension(ID, 'site.footer.status', FooterStatus)
 
+// R13's other slot, and the one that IS named in `module.json` — because it has
+// a server half too (`server/router/admin/usersRust.router.js`). The two halves
+// carry one name on purpose: a module that adds routes under
+// `/api/v1/admin/users/:id` is the module with something to show on that page.
+//
+// Core passes `userId` and nothing else, so the component builds its own client
+// for the routes the server half registered. It renders NOTHING for a user with
+// no linked Steam account, which is most of them.
+registry.registerExtension(ID, 'admin.users.detail', UserRustSections)
+
 // `module.json`'s `coreApi` range was checked by the loader before this file was
 // ever served, so there is nothing to re-check here. Log it anyway: a mismatch
 // between the core that validated the manifest and the core that published this