fix(rust): answer refusals in the field core reads, and show the name the game last saw

The two defects the phase 6 browser walk found and #6 described but did not
carry. They were written, walked and left uncommitted; `edge` still has the
shapes the walk condemned.

**Every refusal sentence was invisible.** Core's request primitive reads one
field — `(data && data.message) || res.statusText` — and this module has
answered `{ error: … }` since phase 1. It got away with it because every
failure until phase 6 landed in `ErrorState` on a page whose whole content was
missing, where a generic sentence is honest. A form is different: the sentence
IS the outcome, and the link page showed *Service Unavailable* for all four of
the refusals phase 6 exists to write. All 23 bodies now answer in `message` —
core's `Error` schema, which these routes' own `#swagger.responses` already
referenced, so the annotations stop being a claim the handlers contradict.

`test/errorShape.test.js` drives each outcome rather than grepping for the
field, and asserts the half that is easy to leave behind: a body carrying BOTH
fields renders correctly in a browser and keeps the wrong shape alive for the
next route that copies it.

**The player saw a stale name.** `/player/rust` showed the name recorded at
link time while the admin panel showed the one the game last saw — the same
person labelled two ways on one site, because a Rust name changes on a whim and
only the admin read joined `rust_players`. A LEFT JOIN, because an account can
be linked and never played on.

123 server tests, 39 client tests, `check:imports`, `check:bundle`,
`check:swagger`, `check:externals` — all green.

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

server/router/admin/usersRust.controller.js

@@ -27,7 +27,7 @@ async function listLinks(req, res) {
     res.json({ links: await links.forAdmin(req.params.id) })
   } catch (err) {
     log.error('failed to read a user’s Rust links', { error: err.message })
-    res.status(500).json({ error: 'Failed to read this user’s Rust accounts' })
+    res.status(500).json({ message: 'Failed to read this user’s Rust accounts' })
   }
 }
 
@@ -50,7 +50,7 @@ async function removeLink(req, res) {
   try {
     const removed = await links.unlinkOwned(steamId, userId)
 
-    if (!removed) return res.status(404).json({ error: 'That account is not linked to this user' })
+    if (!removed) return res.status(404).json({ message: 'That account is not linked to this user' })
 
     // The one write this panel has, so it is the one thing here worth an audit
     // row: after phase 7 a link is what permissions are granted against, and
@@ -64,7 +64,7 @@ async function removeLink(req, res) {
     return res.json({ unlinked: true })
   } catch (err) {
     log.error('failed to unlink a Steam account', { error: err.message })
-    return res.status(500).json({ error: 'Failed to unlink that account' })
+    return res.status(500).json({ message: 'Failed to unlink that account' })
   }
 }