llmmsg-srv drain/register path carries no redelivery marker although priorNotifiedId is in-process at drain time - a re-served message reads as fresh traffic

The shim's two delivery surfaces disagree about redelivery marking, and only one of them carries the marker. NOTIFY path (llmmsg-srv-mcp.mjs:748-761) computes `const redelivered = m.id <= priorNotifiedId` and renders both a '[previously delivered] ' prefix on the content and `redelivered: true` in the meta object. DRAIN path (`formatChannel`, llmmsg-srv-mcp.mjs:687-707) carries NO marker - and `formatChannel` is also what renders the register-time inbox, via `pendingForModel.map(formatChannel)` at :429 under the '--- llmmsg-srv inbox (N messages) ---' header. So a message that was notified but never drained, then re-served on the next session's register, reads as brand-new traffic. NOT A HUB DEFECT AND NOT THE REDELIVERY ITSELF: the hub acks lastDrainedId, not lastDeliveredId (MSG-4 fix(B), deliberate - never lose a message), so cursors.read_id legitimately sits behind a notified-only message and re-delivery is the designed cost, as the file's own MSG-redeliver comment at :69-80 already states. The gap is narrower than that: the flag is in-process and available at drain time, and simply is not used there. MEASURED ON THIS SESSION 2026-09-12: a forked sibling session answered ids 118520/118532/118538 from notifications without ever calling read_unread, so cursors.read_id stayed at 118520 and my register re-served all three as an apparently-new inbox with no repeat marking. priorNotifiedId was 118538, so all three satisfied `m.id <= priorNotifiedId` - the marker was computable and absent. Cost to establish the work was already discharged: ~6 tool calls plus a DB query; re-answering would have sent duplicate traffic to pmmaster-evolutiva-cc and nw-venus-cc. Evidence cited from the file at commit 145fe4a, not from my own inbox render - the copy I received came from a pre-deploy shim (it still carried source= and to=), per memory verify-on-the-path-the-caller-uses. FIX IS NOT A ONE-LINE COPY OF THE NOTIFY PATH: two live shims of one agent share a single per-agent high-water file under STATE_DIR, so the flag cannot distinguish process from agent. The honest wording on the drain path is 'already delivered to a session of this agent', not 'previously delivered by a previous process'. That distinction is the value of this row. BLOCKED ON THE FLEET STOP: message 118424 (pmmaster-evolutiva-cc, 2026-09-12 02:57:16 UTC, kind=decision, relayed and authoritative) suspends shim authoring - 'MSG-400/401 and the hub patch stay SUSPENDED, not cancelled. Nothing to author, nothing to gate.' OPS-228 was the single named exception and is discharged. This row is bookkeeping only; no code was written. Resume needs Elazar's own word.