feat(shard): ingest points.board and publish the leaderboards

Protocol 3.0 §7 (docs/link/v3.md). The shard publishes ~25 points/loyalty
leaderboards — Queen's Loyalty, Void Pool, the nine city loyalties, Clean Up
Britannia — and the site renders them, plus each character's own standings on
their sheet.

Server
  - shard_points_boards: one row per system, keyed by the shard's PointsType
    name. The top-N list stays inside `payload` — a fixed-size list read whole,
    exactly like shard_governors.candidates. Normalizing into an entries table
    buys nothing until something needs a per-character reverse lookup, and a
    character's own standings already ride inside char.profile.
  - shardIngest routes points.board to upsertPointsBoard and deliberately does
    NOT log it: this is board state like guild.update, and the shard emits a
    frame every time anyone's score moves a top ten.
  - uoLinkSocket backfills /points through snapshot() with ingestEach rather
    than a replace*: there is no points.remove and the system set is fixed, so
    upserting IS the reconciliation, and a system the operator later excludes
    keeps its last-known board rather than vanishing.
  - GET /public/shard/points and /points/:system behind
    requireFeature('leaderboards'), both projected per §3.6.1. :system is
    constrained to an identifier before any query runs; 404 for a system never
    published, distinct from a published board nobody has scored in (200, empty
    top).

The leaderboards field rule now keys on `name`, not `characterName`
  Part A pre-wired FEATURES.leaderboards.fields = { characterName: ... }, but
  projectValue matches on the LITERAL JSON key and the wire key is `name`. As
  written the rule was inert: an admin tightening character names would have got
  no enforcement and no error — precisely the failure §3.6.1 records for the
  flattened `ownerAcct` spelling. Fixed, with a test that fails if it is renamed
  back, and the admin panel's FIELD_LABEL carries the meaning instead.

Client
  - routes/public/Leaderboards.jsx at /site/leaderboards. A points.board frame
    describes ONE system, so live frames merge over the fetched set by system
    key rather than replacing it wholesale the way the ruleset does. Filter
    matches board name, system key, or any ranked player — the last is what
    makes it useful ("where do I appear?").
  - A "Loyalty & Points" section in CharacterSheet.jsx, one edit serving both
    PlayerCharacter and AdminCharacter.
  - Both treat maxPoints: 0 as UNCAPPED and both fall back to humanising the
    system key when nameString is null. Neither is defensive padding: on a real
    shard uncapped and cliloc-only names are the majority case.

Verified end to end against the local MariaDB, the Rust sidecar, and the real
ServUO shard: backfill from /points, live SSE delivery (a board absent from the
initial fetch appearing without a reload, and an existing one updating in
place), REST reflecting the overwrite, and the gate at every rung — 200 by
default with names, names stripped but points kept at fieldRules name=staff, 403
plus dropped from /features at audience=staff, 404 when disabled. Page rendered
clean, no console errors beyond the pre-existing React Router v7 warnings.

605 server tests pass; routes.manifest.json, routes.guards.json and the OpenAPI
spec regenerated.

Co-Authored-By: Claude <noreply@anthropic.com>

server/test/shardVisibility.test.js

@@ -150,6 +150,49 @@ test('rule 1 matches FLATTENED spellings, not just the two canonical keys', () =
   assert.equal(asAdmin.ownerAcct, 'cadmus_acct')
 })
 
+// ── Protocol 3.0 leaderboards ──────────────────────────────────────────────
+//
+// The leaderboards field rule is spelled `name` because that is the key
+// points.board actually puts a ranked character's name under. v3.md §7.4 calls it
+// "characterName", which describes the meaning — and projectValue matches on the
+// literal key, so a rule under that spelling would have been silently inert. This
+// is the same failure mode §3.6.1 records for the flattened `ownerAcct`, and this
+// test is the guard on it: if someone renames the rule back, an admin who tightens
+// character names would get no enforcement and no error.
+test('a tightened leaderboards name rule actually strips ranked character names', async () => {
+  withRows([
+    { feature: 'leaderboards', enabled: true, audience: 'anonymous', stream: true, fieldRules: { name: 'logged_in' } },
+  ])
+  const config = await visibility.getConfig()
+  const board = {
+    system: 'QueensLoyalty',
+    nameString: "Queen's Loyalty",
+    top: [{ rank: 1, serial: '0x1A2B', name: 'Darrow', points: 29500 }],
+  }
+
+  const anon = visibility.projectFeature('leaderboards', board, 'anonymous', config)
+  assert.equal('name' in anon.top[0], false, 'anonymous must not see the ranked name')
+  assert.equal(anon.top[0].points, 29500, 'the rest of the entry survives')
+  // The BOARD's own display name is a different key and must not be caught by it.
+  assert.equal(anon.nameString, "Queen's Loyalty")
+
+  const member = visibility.projectFeature('leaderboards', board, 'logged_in', config)
+  assert.equal(member.top[0].name, 'Darrow')
+})
+
+// Default config: boards are public, exactly as v3.md §7 specifies.
+test('leaderboards are anonymous-visible by default, names included', () => {
+  const config = visibility.compileDefaults()
+  const out = visibility.projectFeature(
+    'leaderboards',
+    { top: [{ rank: 1, name: 'Darrow', points: 1 }] },
+    'anonymous',
+    config,
+  )
+  assert.equal(out.top[0].name, 'Darrow')
+  assert.equal(visibility.kindVisibleTo('points.board', 'anonymous', config), true)
+})
+
 test('isLockedField locks acct/webId and their suffixed forms, and nothing else', () => {
   for (const key of ['acct', 'webId', 'WEBID', 'ownerAcct', 'leaderWebId', 'governorAcct']) {
     assert.equal(visibility.isLockedField(key), true, `${key} must be locked`)