docs(website): settle the three de-entanglement registries and what they cost

Phase 2 PR 4 of MODULE_SYSTEM.md §2.7. Records what §1.8's three entangled files
and §1.9's extension slot actually became, and four decisions taken with them.

MODULE_API.md §2.4:
- registerNotificationStreams takes the catalog ALONE. `mapEvent` was a leftover
  from before §1.8's push inversion was settled — a module owns fromShardEvent
  and calls publish() with an id it resolved, so core never needs a second route
  to the same place. It follows that the public-safety filter is module-internal,
  which is the right home: the kinds, the streams and the filter become one file
  that moves together.
- the entry shape is two booleans, not a single `scope` — that object is the body
  of GET /auth/me/notifications/streams and a shipped Android client reads both.
- registerAnnounceLeg gains `label`, so a module's leg renders in the admin panel
  with no client change; and legs became `announce_job_legs` ROWS, because a
  module cannot ALTER a core table and a registered leg had nowhere to live.
- every call STAGES; nothing commits until the module as a whole is known good.

New §6.5 — the eight grandfathered names (seven stream ids, one leg id), allowed
to `uo` alone by explicit allowlist, the same shape as the loader's legacy table
prefixes. Grandfathering rather than dropping the rule is what keeps it real for
every module written after this one.

New §6.6 — an extension slot is invisible to static analysis, so core needs §6.1's
fragment merge for its OWN slot fills, a phase earlier than the plan expected.
Moving the six users-detail routes behind the slot deleted 407 lines from
swagger-output.json while printing `Success`. Which slots and where each hangs are
both derived — from the registry and from the live express stack — because a
written-down copy drifts.

MODULE_SYSTEM.md §1.8 / §1.9 record the outcome per file, and §2.7 the progress.
BACKEND_DESIGN.md and website-README.md follow the moved files; the PUBLIC_KINDS
reference at §"visibility" named the wrong file and is corrected to
utils/shardBroadcast.js.

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

website/BACKEND_DESIGN.md

@@ -365,7 +365,7 @@ A DB read never yields a usable reset link. See §4 `/auth/password/*`.
 | col | type | notes |
 |---|---|---|
 | user_id | INT NOT NULL FK→users(id) ON DELETE CASCADE | |
-| stream_id | VARCHAR(64) NOT NULL | an id from the catalog (`config/notificationStreams.js`), validated on write |
+| stream_id | VARCHAR(64) NOT NULL | an id from the catalog (`modules/registries.js` — core's plus every installed module's), validated on write |
 | created_at | DATETIME | |
 
 `PRIMARY KEY(user_id, stream_id)`. Subscriptions are per-user (applied to every device); a PUT
@@ -793,14 +793,18 @@ registers device endpoints (`/auth/me/devices`); nothing is pushed unless subscr
 self-hosted **ntfy** endpoint (`utils/pushDispatch`); the app wakes and pulls the real, ownership-
 checked content over the authenticated API. Two producers fan out through the one publisher: the shard
 ingest dispatcher (`utils/shardIngest`, beside the SSE broadcast) for shard-derived streams, and the
-create/publish-post path for `news.post`. The stream catalog + event→stream mapping is
-`config/notificationStreams.js`. Security invariants:
+create/publish-post path for `news.post`. The catalog is assembled at boot by
+`modules/registries.js` from core's own streams (`config/coreStreams.js` — just `news.post`) plus
+each installed module's; the shard streams and their event→stream mapping are
+`config/shardStreams.js`, which belongs to module-uo and moves out with it
+(MODULE_SYSTEM.md §1.8). Security invariants:
 - **Same public/admin split as the SSE feed.** Public streams are drawn *only* from the SSE
   `PUBLIC_KINDS` allowlist; a sensitive kind (audit/cheat/IP/login-attempt) can never produce a public
   push.
 - **Personal streams are owner-keyed.** `vendor.sale` / `house.idoc` / `account.login` are delivered
   only to the *owning* user's devices, resolved via `shardLinks` (the same ownership check as
-  `/player/shard/*`).
+  `/player/shard/*`) in `utils/shardPush.js`. `utils/pushDispatch.js` itself only publishes to a
+  stream id someone else resolved — it has no idea what a shard event is.
 - **SSRF guard.** A device `endpoint` is a client-supplied URL the server POSTs to, so registration and
   every publish validate it is HTTPS, non-private/loopback, and (when configured) on the shard's ntfy
   allow-set (`NTFY_BASE_URL` / `NTFY_ALLOWED_ORIGINS`).
@@ -1130,7 +1134,7 @@ it picks, it fails open on one side.)
 | Nav | `GET /public/shard/features` returns only what the caller may reach, so the SPA never renders a link that would 403. Presentation only. |
 
 Config reads are cached ~5s, so admin changes take effect within seconds **including on already-open
-streams**. `PUBLIC_KINDS` still exists and is still exported (`notificationStreams.js`) but is now
+streams**. `PUBLIC_KINDS` still exists and is still exported (`utils/shardBroadcast.js`) but is now
 **derived** from the kind map rather than hand-maintained, so the two cannot drift.
 
 **`PUBLIC_KINDS` is a module-load constant and must not be used to answer "may this caller read this