Expose the persisted patch ledger through operation_status

[novelKR]

Issue

Closes #

Summary

operation_status now returns the recorded patch ledger so a client can recover files, before/after hashes, and minted/finished events after a lost apply response. Commands stay on process_id and are not written to operations.

Contract changes

• operation_status remains the same tool name (LIVE_TOOLS unchanged). XOR lookup (operation_id or operation_key) and lookup replayed: false are unchanged.
• Additive OperationStatusResult fields: kind ("patch"), workspace_id, created_at, optional finished_at, files, changes, events.
• Unfinished rows have no finished_at. A transport-ambiguous close records a finished event with reason: "unknown".
• Existing DBs gain finished_at and events_json via idempotent ALTER TABLE.

Tests

Verified locally:

• cargo test -p codespace-domain -p codespace-store --offline
• cargo clippy -p codespace-domain -p codespace-store -p codespace-server --all-targets --offline -- -D warnings
• cargo test -p codespace-server --offline --lib apply_patch_uds_loss
• cargo test -p codespace-server --offline --test operations --test protocol_compat --test rollback
• python3 -B scripts/check_docs.py check

Security scenarios

• V4A patch text is still not stored; the ledger holds observed file hashes only.
• operation_id / operation_key remain selectors, not credentials.
• Exec/process_id is not recoverable through operation_status, so a lookup cannot be mistaken for process recovery after restart or UDS loss.

Out of scope

• Recording exec in operations or looking up commands via operation_status
• New MCP tools, LIVE_TOOLS changes, Runner DTO operation identifiers
• Approval resume, fs/watch, PTY resize, disconnect recovery, resource scheduler

Made with Cursor