[codex] Persist Kimi homes after provider failures

[Unluckyathecking]

Summary

• Persist isolated Kimi HOME under .omk/runs/<runId>/kimi-home/<node> when run/session metadata is available.
• Retain that HOME on Kimi provider failures, including rate-limit and quota exits, and print the preserved session/subagent path for recovery.
• Resume recorded Kimi session IDs when omk chat --run-id is used.

Why

Rate-limit or quota failures can kill Kimi subagents before their in-flight sessions are inspectable or resumable. The previous temp HOME cleanup removed .kimi/sessions/.../subagents evidence immediately, which made recovery impossible after provider-side failures.

This keeps recovery artifacts scoped to the OMK run while preserving cleanup on successful exits, startup failures, user stops, and orchestrator/controller stops.

Validation

• npm run build
• npm run check
• npm run lint
• npm test (83 files passed)

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c9342905ed

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Ensure isolated HOME cleanup runs on runner exceptions

Wrap the runShellStreaming call in a try/finally so cleanupIsolatedKimiHome(tmpHome) executes even when runShellStreaming rejects before producing a result (for example, log-path creation or spawn/setup errors). In the current flow, those exceptions bypass cleanup entirely, leaving the isolated HOME (including symlinked auth material) behind and violating the intended behavior of cleaning up on non-provider failures.

Useful? React with 👍 / 👎.