Design: unified memory-change delivery through the Inbox (render after prepare) #349

Problem

Two delivery paths exist for one phenomenon. Out-of-band Memory changes reach the turn through a bespoke memory-local take-once map (#329), while any future UI-save event would want the Inbox. Take-once has no persistence and no visibility; the Inbox cannot carry lazily observed changes today because inbox text renders before prepareTurn runs.

Decision (design only, no implementation in this issue)

Reorder the orchestrator wake path so inbox renders after prepareTurn:

• Prepare-time worktree diffs create an Inbox Admission (reason: memory-change) consumed by the same turn's render. Raw-disk edits stay lazy - no watcher, per ADR-0047.
• UI and API saves may admit eagerly at save time with join-without-wake semantics (digest precedent); the lazy path remains the catch-all.
• Admission render carries paths only, same bounds as the current annotation (never bodies). Rapid saves coalesce (Attention Unit precedent).
• Baseline updates stay at reconcile and abort ends. Bottom-only delivery preserved: the inbox block is turn message, not prefix (ADR-0060).
• The take-once machinery is removed when this lands.

Seams touched

Wake sites (DM, group, digest, report, resume paths), the runtime turn signature (inbox passed pre-rendered today), one admission reason, one render rule, one wake-policy mode.

Out of scope

Implementation (future slice); save-time admission UI; filesystem watcher; the read-only transparency row alternative.

Rejected alternatives

• Status quo take-once forever: works and verified, but leaves delivery split if a second event kind ever needs the Inbox.
• Inbox without reorder: structurally one turn late for lazily observed changes (render precedes observation).

Refs #324, #329, #47, #152.