sminos plane: mark the rows off the live chain in DX4 (7.179.0)

[SSFSKIM]

The desk drew every row a transcript holds, in file order, so it drew dead branches: the owner's prompt sent again after an Esc showed as two bubbles, and a steer appended under a turn an Esc or a /rewind undid showed as if the session had read it. The engine reads only the chain from the transcript's leaf; the machine holds the whole file, so the session plane now marks the rows off that chain in DX4 (the general fix MAWS's tech-debt row for DC9 named).

What changes

skills/sminos/scripts/sminos_plane.py: a Chain per transcript follows the engine's writes row by row and knows which rows are on the live chain. Each transcript's shared chain is fed with its index on the worker; a build hands the subscription a copy as of its offset, and the subscription feeds it each row as it releases it, so every mark is read off the subscription's own chain in message order.

DX4, additive (an older desk ignores the fields and keeps working):

• snapshot: offChain: string[], the uuids among its rows off the chain (always present, possibly empty).
• rows page: offChain: string[], the same for the page's rows (marked on the uplink's thread from the subscription's chain, so a page never contradicts a row sent before it).
• row: offChain?: string[] and onChain?: string[], present only when non-empty: the rows this row took off the chain (the rows a branch it starts left behind, oldest first, and itself when it is written off the chain) and the rows it put back on.

The chain rules (the engine's, 2.1.300)

A row's parent is normally the leaf. A tool result names its issuing assistant (sourceToolAssistantUUID), so parallel calls' results, and anything delivered between a call and its result (a steer, a task notification), sit off the leaf's ancestry while the engine holds them: a tool result joins while its assistant is on the chain and moves nothing else. Any other row whose parent is not the leaf starts a branch: the rows after the branch point go off, except a tool result whose assistant stays on and an assistant of a response that does (the loader's ato recovery); rows a branch had taken off come back if a new branch runs through them. A tool result whose assistant is off is off too. A row whose parent is not placed yet waits (the engine writes a child a few ms before its parent around a session's start); a null parent (a compaction's boundary) continues the chain, so pre-compaction history stays drawn. Progress rows pass through; a main transcript's sidechain rows are never marked.

Checked against 1,500 transcripts on this machine (667k rows, 2.6 µs a row): 870 branches took 9,987 rows off, every one a re-sent prompt, a /rewind, or a response the engine dropped when a message reached its turn; after each file's last compaction the final chain equals the engine loader's reconstruction (ancestry, response-group recovery, tails, leaf descendants) except one deliberate divergence: a plain user row delivered between a call and its result stays on (the live engine read it; the loader drops it on resume).

Tests

tests/sminos/test_session_plane.py: ChainRules (a re-sent prompt, a steer that stays on through its turn and goes off with it, parallel results kept, a dropped response, rows ahead of their parent, compaction, a late result of an undone call, a branch back, progress and sidechain rows, an independent copy) and OffChain through a subscription (snapshot and pages marking an undone turn, a rewound prompt beside parallel results, a live rewind whose re-sent prompt carries the retraction through the bridge's release order, rows past the cut carrying their own marks, an agent's transcript). All fail on main. Full sminos suite 1928/1928 locally; ci-gate GREEN on 686cf6e (https://github.com/SSFSKIM/doperpowers/actions/runs/39124943916).

Review

doperpowers:reviewer-medium, three bounded rounds. Round 1 found two real defects in rejoin paths (a branch running back through rows another branch took off restored only its own ancestry, not the response's other calls and results the loader recovers; a waiting-row cascade could report intermediate moves): fixed in d291ea0, each pinned by its reproduction. Round 2 found the recovered rows rejoining out of order: fixed in 3e64f1d (they rejoin in file order), pinned. Round 3: no material findings. No branch has ever put rows back on across the 1,500 local transcripts, so those paths are rare.

Known gaps (docs/doperpowers/TECH-DEBT.md)

• A retraction lands with the branch's first row (the re-sent prompt, a delivery, a system notice), not at the Esc: the interactive engine writes nothing when it hands a prompt back.
• An Esc that empties the conversation (the session's first prompt) leaves no branch: the engine writes its next row under the stale leaf, so the file's chain runs through the prompt the live conversation dropped (sminos bridge: after an Esc, the owner's words go in as a row; the inbox carries only the wake (7.178.0) #238's evidence, run 7 restore). The only trace, a zero-leaf explicit last-prompt, names no cut.
• A row whose parent never appears stays unplaced and unmarked (1 of 1,500 transcripts, a resumed subagent).

No bridge change: the mod's row notices carry no parent, and need not, since the plane reads each row's parentUuid from disk and releases a row only once it is there.

The desk side is MAWS's PR (see there).