design: define completed worker tmux session lifecycle cleanup

[devkade]

Problem

During the scheduled Ilchul issue cron run, the runcontract-track worker tmux session remained alive after the associated workflow/PR work was completed and merged.

Evidence

• Session: runcontract-track
• Associated work: Track A RunContract formatting cleanup, PR refactor: consolidate Track A RunContract formatting #132 (refactor: consolidate Track A RunContract formatting), merged into dev at merge commit ab2448c64e3a16c3d3d57847ddf3d75ecd5fe3f4.
• Worker pane reported KAPI_READY runcontract-track hzlfvgub and listed completed verification:
  • npm test — pass
  • npm run check — pass
  • npm run check:unused — pass
  • npm run quality:budgets — pass with existing code_smells warning
  • git diff --check — pass
• Non-destructive close attempts were made via tmux input:
  • sent /exit → pane responded Done. but tmux session still existed
  • sent /quit → tmux session still existed
• Current observation command:
  • tmux has-session -t runcontract-track still succeeds after those close attempts.

Why this matters

The recurring issue-to-PR cron should not silently leave completed worker sessions behind. If normal workflow completion does not close or mark completed sessions, supervisors cannot distinguish healthy retained logs from stale worker lifecycle leaks.

Reproduction / inspection

1. Complete an Ilchul/Kapi worker-backed issue workflow through PR merge.
2. Attempt safe CLI/session close via the interactive worker command path (/exit, /quit).
3. Check tmux has-session -t <workflow-slug>.
4. Observe that the session may remain alive even though the workflow is complete.

Decision questions

• Should completed worker tmux sessions be auto-closed, marked terminal, or intentionally retained for audit?
• If retained, what machine-readable state should tell the cron supervisor that the leftover session is expected?
• Which command/surface should Ragna use for safe cleanup without killing active work?

Acceptance criteria

• Completed workflow sessions have a documented lifecycle state.
• The supervisor can determine whether a tmux session is active, completed-retained, stale, or safe-to-close.
• Safe cleanup does not require destructive tmux killing or branch/worktree deletion.