release: N-1 growth postures consciously accepted (all three engines)

The wave-8 N-1 deferred item — re-read the three unconditional-growth
paths against the implemented engines and land the decision of record:
all three accepted for v1, per engine, with no engine-side hygiene.

- deployment.md: new 'Growth postures (consciously accepted)' section —
  per-engine table (dead letters sweep-on-call, SQLite-only notify
  at-attach cap, durable-log stream posture; mem process-lifetime-
  bounded by design) + the rationale and the deployment-matrix
  fold-in positioning.
- engine-sqlite.md: 'Notifications-table hygiene' — attach is the only
  prune site (D-16, oldest-first 10k); idle-but-listening processes
  never prune; the cadence caveat deployers should size for.
- tasks/release-n1-growth-posture.md: completed; Notes/Summary filled.

docs/architecture/engine-sqlite.md

@@ -1,6 +1,8 @@
 ---
 status: stable
-last_updated: "2026-10-10 (review-wave-5 gate: the verification backlog fully discharged in the version-stamped contract suite, green against this engine; spec flipped draft → stable)"
+last_updated: "2026-10-11 (the notify prune-cadence note — the
+notifications table's at-attach-only hygiene sharpened, accepted at
+the growth-posture review)"
 ---
 
 # SQLite engine
@@ -108,6 +110,29 @@ per-contract obligations live in the core spec and are not restated here.
   over mpsc — measured ~2× the spawn_blocking shape at p50 in POC #1),
   or a raised watcher cadence for idle CPU. Neither is the default.
 
+### Notifications-table hygiene
+
+The `__alkstore_notifications` table (this engine's notify wake
+transport) is pruned to its newest 10,000 rows, oldest-first —
+the at-attach cap (ADR-010 §6, register D-16) — and the attach is
+the **only** prune site: the prune runs at every connection open (the
+substrate's bootstrap); there is no background sweeper, no
+time-based retention, and no consumer-visible prune operation — the
+table stayed off the contract surface by ADR-008 §4's disposition
+(upstream's `prune_notifications*` helpers are not carried).
+
+The consequence a deployer should size honestly: an idle-but-listening
+process — one that opens its connections at startup and holds them —
+attaches never, so nothing trims the table; every committed notify
+across the fleet lands a row and the table grows past the cap until
+the next attach (a reconnect, a second `open` of the same file by any
+process, or a restart). Attach-prune is hygiene at open, not retention
+at runtime. Long-lived, notify-heavy single-process deployments should
+either budget an attach event into their runbook or size the table
+deliberately. Accepted with that caveat at the growth-posture review;
+the per-engine record lives in [deployment.md](deployment.md)'s growth
+postures.
+
 ## What the fork question resolved
 
 The [quality read (OQ-06)](../research/quality-read-honker-core.md) —