bug(recovery): restored panes never read their ghost log (crash-resume bootstrap dead since July) #1225

Found by the #1223 review (reviewer A, 2026-09-25). Class C2 (identity across restore).

Problem

The crash-resume ghost bootstrap in docs/design/ghost-system.md ("Crash + restart") has been dead since 0cb71e99 (2026-07-16, "Make session recovery main-owned and atomic"):

• The only reader of a persisted ghost log is window.api.ghostRead(sessionId) at src/renderer/src/workspace/hook/actions/session.ts:597, inside spawn. There sessionId is the id SessionManager.spawn just minted with randomUUID() (sessionManager.ts:2169), so it can only ever find an empty log.
• Restored panes go through ensureSessionLive → session:recover with their persisted id. That path never calls ghostRead; there is one call site in all of src/.
• Undo Close, the Resume picker, provider switch and duplicate all respawn under a fresh id.

User impact: a pane that crashed mid-turn comes back without the provisional rows its ghost log holds, for exactly the turns where the committed transcript is incomplete, which is what ghosts exist for. It also means every ghost log is write-only today, which is why #731's re-append was never observed.

Acceptance

• Recovering a pane under its persisted id reads that id's ghost log and reconciles it against the loaded transcript. This is the bootstrap session.ts:580-640 does, moved onto the recover path.
• Test with a real ghost log (from <userData>/ghost-logs/) plus the matching recorded transcript; it must fail on the current code.

Related

• fix(storage): prune orphaned ghost logs; protect a ghost log only while its session exists #1223 keeps owned logs protected in the meantime; its owner key (workspace plus running ids) is the right one for a recover-path reader.
• bug(renderer): resume re-appends the entire ghost log every time #731 re-opens once this reader exists.