Expose state-DB backfill owner identity or a sanctioned stale-backfill repair RPC

Problem

Codex 0.146.0 can leave backfill_state.status = 'running' after the process performing a large state-DB backfill is killed. The row records progress but not enough process identity for an embedding application to prove whether the owner is still alive.

Subsequent Codex processes wait about 30 seconds, report that the local database appears damaged, and exit with timed out waiting for state db backfill ... (status: running). Short-lived clients can later claim the expired lease and be killed before a large history finishes, refreshing the wedge indefinitely.

This was observed with a managed CODEX_HOME containing 4,829 rollout files / about 14 GB on Windows 11 + WSL2 Ubuntu: https://github.com/stablyai/orca/issues/11830 (background: https://github.com/stablyai/orca/issues/11828).

Request

Please expose a sanctioned way to distinguish a live backfill from an abandoned one and recover without third-party schema writes. Either of these would address the integration gap:

• Persist exact owner identity with backfill_state (host / PID namespace, PID, and process start identity rather than PID or age alone) and let Codex safely take over a confirmed-dead owner.
• Add an app-server or codex doctor RPC that reports backfill ownership/progress and repairs, releases, or durably supervises an abandoned backfill.

The contract needs to work for native macOS/Linux/Windows plus WSL and SSH-hosted homes, where identical PID values can belong to unrelated hosts or process namespaces. CPU activity and record age are not safe liveness signals, and integrators should not have to mutate Codex-owned SQLite schema directly.