docs(handoff): finish the ADR-0030 retirement — the runbook's own description too

The first pass tombstoned only the cut-over sequence's step 2. Three claims
above it still described the migration as live: the `### Data migration
(not auto-run)` section that names the deleted file and its export, the
breaking-change callout telling a reader to "do the objectui cut-over and the
data migration together", and the Tests line counting the migration's own
suites among the green ones.

Found by the docs-drift round on the PR. The runbook tombstone is now a
pointer to the one full account, so the file states it once.

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

Author: claude

docs/handoff/adr-0030-notification-convergence.md

@@ -62,24 +62,43 @@ a per-user inbox row directly.
   a `dedupKey`. No more direct `sys_notification` writes. The plugin resolves the
   `messaging` service lazily at hook time (`audit-plugin.ts`).
 
-### Data migration (not auto-run)
+### ⚰️ Data migration — RETIRED, there is none
+
+This section used to describe
 `packages/metadata/src/migrations/migrate-sys-notification-to-event.ts`
-(exported from `@objectstack/metadata/migrations`). Splits each legacy
-`sys_notification` inbox row into `sys_inbox_message` + a receipt, rewrites the
-row to the event shape, and clears the legacy columns. **Idempotent**; reports
-`not_applicable` on fresh installs.
+(exported from `@objectstack/metadata/migrations`), which split each legacy
+`sys_notification` inbox row into `sys_inbox_message` + a receipt, rewrote the
+row to the event shape and cleared the legacy columns.
+
+**That runner is gone (#16194).** It had zero production callers and no
+`os migrate` sub-command, and both ways of giving it one were refused: an
+operator door is a permanent surface for a migration with no measured demand,
+and a boot-time invoker is an unattended data rewrite. ⇒ **Pre-ADR-0030
+`sys_notification` rows are not carried by the platform on this line.** After
+the cut-over the bell shows rows emitted from the new pipeline onward; older
+per-user inbox rows stay where they are, unread by the new UI.
+
+⚠️ Nobody has measured whether any live deployment still holds pre-ADR-0030
+`sys_notification` rows. If **your named deployment** does and needs them, ⛔ do
+not re-add the call — the migration returns as an operator-runnable `os migrate`
+sub-command shaped exactly like `files-to-references` / `value-shapes` (dry-run
+default, `--apply` gate, documented consequence), under its own card. Say so on
+#16194.
 
 ### Tests
-`messaging-service`, `inbox-channel`, `messaging-service-plugin`, `notify-node`,
-and the migration all have updated/added coverage. All green.
+`messaging-service`, `inbox-channel`, `messaging-service-plugin` and
+`notify-node` all have updated/added coverage. All green. (The migration's own
+suites went with the runner.)
 
 ---
 
 ## ⚠️ Breaking change — Console bell (objectui, separate repo)
 
 The bell read `sys_notification.{recipient_id, is_read, title, body, …}`. Those
 fields **no longer exist**. Until objectui is updated, the bell will be empty /
-error. **Do the objectui cut-over and the data migration together.**
+error. ⚰️ There is **no data migration to pair it with** any more (see above):
+do the objectui cut-over on its own, and expect the bell to start from the
+rows the new pipeline emits.
 
 ### objectui changes required (`app-shell`)
 1. **`AppHeader.tsx` / `InboxPopover.tsx`**: poll **`sys_inbox_message`** filtered
@@ -103,23 +122,13 @@ error. **Do the objectui cut-over and the data migration together.**
 (Step order tolerates a brief window where new rows exist but the UI hasn't
 flipped — the inbox is being populated the whole time.)
 
-> ⚰️ **The data-migration step is GONE.** This runbook used to carry a step 2,
-> `migrateSysNotificationToEvent({ driver, data })`, that carried pre-cut-over
-> `sys_notification` rows into `sys_inbox_message` + receipts. The runner has
-> been **retired** (#16194): it had zero production callers and no `os migrate`
-> sub-command, and both ways of giving it one were refused — an operator door is
-> a permanent surface for a migration with no measured demand, and a boot-time
-> invoker is an unattended data rewrite. **Pre-ADR-0030 `sys_notification` rows
-> are not carried by the platform on this line**: after the cut-over the bell
-> shows rows emitted from the new pipeline onward, and older per-user inbox rows
-> stay where they are, unread by the new UI.
->
-> ⚠️ Nobody has measured whether any live deployment still holds pre-ADR-0030
-> `sys_notification` rows. If **your named deployment** does and needs them, do
-> not re-add the call — the migration returns as an operator-runnable
-> `os migrate` sub-command shaped exactly like `files-to-references` /
-> `value-shapes` (dry-run default, `--apply` gate, documented consequence),
-> under its own card. Say so on #16194.
+> ⚰️ **This sequence used to have three steps.** The middle one was
+> `migrateSysNotificationToEvent({ driver, data })`, carrying pre-cut-over
+> `sys_notification` rows into `sys_inbox_message` + receipts. That runner is
+> retired (#16194) and **pre-ADR-0030 rows are not carried by the platform on
+> this line** — the reasoning, the unmeasured-deployment caveat and the reversal
+> path are in [Data migration — RETIRED](#-data-migration--retired-there-is-none)
+> above. ⛔ Do not re-add the call here.
 
 ---