Flows: recover a running flow without its id on harnesses that give the flows server no session #1123

Problem

get_review_flow_status / get_flow_status recover a running flow without its flow_run_id by listing the flows the calling session started (#1103). That lookup is keyed on the session id the flows server resolves at startup, which exists on Claude Code (CLAUDE_CODE_SESSION_ID) and Codex (CODEX_THREAD_ID) only. Cursor, Copilot, Gemini, Kiro, OpenCode and Antigravity export no per-process session signal into the long-lived MCP server child — the --driver <vendor> stamp names the harness, not the session — so on those harnesses a start carries no requesting_session_id and a bare status call answers the "no session id" error. A driver there whose harness aborted the start, or whose context was compacted, still has no way back to the run.

Proposal

Give the flows server a handle that does not depend on a harness session id. Two shapes worth weighing:

• A local run ledger. The flows server records every flow_run_id it received from a start, keyed on its own working directory and repo, in the config root. A bare status call on a harness with no session identity reads the newest open run from that ledger and confirms it against the server. Covers the aborted-start case only when the start reply reached the server process at all, which it does: the CLI's poll lane holds the id before the harness aborts the tool call.
• A harness-provided session id. Where a harness exposes one to hooks (Cursor's conversation id, Copilot's session id) the hook could write it somewhere the MCP server can read it per process; the registration's --driver stamp shows there is no such channel today.

Acceptance

• After a harness abort of start_review_flow on Cursor (or any other JSON harness), a bare get_review_flow_status(wait: true) reaches the run and returns its result.
• The tool descriptions and both flow skills drop the Claude Code / Codex qualifier on the bare call.