docs(shard): record the REST projection gap the Part A smoke test found

The live five-rung smoke test of the visibility framework found that Part
A enforced it on the SSE path and on /guilds + /governors, but not on the
remaining public REST reads - so one event was projected live and served
verbatim from stored history.

link/v3.md gains 3.6.1 with the full list (the anonymous acct/webId leak
on /feed, the flattened ownerAcct on /idoc, the dead `houses` field
rules, /feed ignoring live config, the empty-allowlist fall-through, and
the Date-to-{} projection bug), plus the rule it leaves behind: a read
path that returns shard data and does not project is a bug, and every new
Part B/C surface must gate its kind set on live config rather than on
PUBLIC_KINDS.

3.5 also corrected: the table is NOT seeded on boot. An absent row means
"use the compiled default", which keeps the defaults in one place instead
of duplicating them into a seeder that could drift.

BACKEND_DESIGN.md 6.5 records the same as a security contract: rule 1
locks a field by meaning rather than spelling; PUBLIC_KINDS is a
module-load constant and must not answer per-caller questions;
projectFeature walks arrays and plain objects only.

SHARD_VISIBILITY.md gets the admin-facing version - that stored history
answers the same way the live stream does, and that turning live updates
off stops the push, not the reading.

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

website/SHARD_VISIBILITY.md

@@ -80,6 +80,11 @@ game to anyone standing next to them; the **account** behind it is not, and neit
 user it's linked to. Publishing those would disclose something the shard itself doesn't, and would
 tie a player's in-game identity to their forum identity without their consent.
 
+This rule matches the *meaning* of a field, not one spelling of it. Some responses nest the player
+who owns a record (`leader.acct`); others flatten it into the row (`ownerAcct`, `leaderWebId`,
+`governorAcct`). Every one of those is locked, and the admin API refuses to configure any of them —
+so a new response shape can't quietly reopen the hole by naming the field differently.
+
 **2. Unknown event kinds are never broadcast below admin.**
 The live stream maps each event kind to a feature. A kind with no mapping — a new event from a shard
 plugin the site doesn't know yet, say — goes to admins only. It fails closed. This is what keeps the
@@ -99,6 +104,15 @@ Three places, one config:
 - **Navigation** hides links a viewer can't follow, so they don't hit a wall. This is presentation
   only — the gate is server-side either way.
 
+**Stored history answers the same way the live stream does.** The activity feed reads from the event
+log rather than the live stream, but it resolves the *same* question against the *same* config: which
+kinds you may read, and which fields survive. So moving a feature up a rung hides it from the history
+as well as the stream — there is no back door where yesterday's copy of an event is more revealing
+than today's.
+
+One deliberate asymmetry: turning **live updates** off for a feature stops the push, not the reading.
+The marketplace ships this way — its history and its pages are public, only the firehose is off.
+
 Changes take effect within about five seconds, **including on streams that are already open**. You
 don't need to restart anything.