fix(cli): TUI /resume can never succeed — safe-boundary resume disabled by unset env flag

[me2seeks]

What happened

/resume in the TUI always surfaces a red error with an internal protocol reason:

Note: Resuming from the latest safe boundary…
Error: Safe-boundary resume parked: continuation_unavailable

Safe-boundary resume is an intentional opt-in feature, gated by MAKA_RUNTIME_SAFE_BOUNDARY_RESUME=1 (documented in README and docs/architecture/runtime-resume-architecture.md, shipped as Phase 1 in #1996). So the flag being off by default is by design. The defect is in how the TUI communicates that design:

1. When the flag is off (the default), the host parks the resume plan with resume_feature_disabled → continuation_unavailable, and the driver throws it as a plain Error whose message is the raw protocol enum. A user who never set the flag sees a red error that reads like session corruption, with no hint that this is an opt-in feature they could enable.
2. Even with the flag enabled, /resume after a completed turn parks with resume_candidate_missing and renders as the same kind of red error — yet "no interrupted run exists" is a normal state, not a failure.

So the surfaced message conflates three very different situations (feature disabled / nothing to resume / real safety block) into one opaque red continuation_unavailable-style string.

How to reproduce

1. Start the TUI (maka), send any message so a session and run exist
2. Type /resume
3. Observe Error: Safe-boundary resume parked: continuation_unavailable

Second experiment (with MAKA_RUNTIME_SAFE_BOUNDARY_RESUME=1): after a completed turn, /resume reports resume_candidate_missing — accurate, since resume only targets failed/cancelled runs, but still shown as a red error. After the provider actually fails mid-turn, /resume does re-drive the interrupted turn. So the resume machinery works end-to-end; the issue is purely how the "parked" outcome is surfaced.

Environment

• Maka version or commit: 944d822 (main, v0.1.11)
• OS and version: Linux x64
• Surface: TUI / CLI
• Node.js version, if running from source: 26.3.0

Expected behavior

The parked outcome is the host saying "there is no safe continuation to run right now", which is informational, not an error. The TUI should:

• distinguish the reasons with plain-language copy instead of the raw enum:
  • continuation_unavailable → "Safe-boundary resume is not enabled on this runtime (set MAKA_RUNTIME_SAFE_BOUNDARY_RESUME=1 to enable)."
  • resume_candidate_missing → "Nothing to resume: no interrupted run exists in this session."
  • session_busy → "Cannot resume: the session already has an active turn."
• render these as informational notices, keeping red errors for genuine failures (safety_check_failed, source_run_unreadable, etc.).

This keeps the opt-in design intact while making /resume honest about why it did nothing.

Logs, screenshots, or additional context

The user-facing copy for /resume ("Resume latest interrupted run at a safe boundary") promises an action that, by default, can never run — and when it doesn't, the feedback points at the session rather than at the feature flag. The obscure internal reason string is what makes users (me) conclude the command is simply broken rather than gated.

Related: #3308 fixed a different /resume defect (steering the literal text into a running turn); this one is about the surfaced outcome of a parked resume plan.

[me2seeks]

I'm working on this — preparing a fix that makes /resume fail gracefully (informational notice instead of a raw error) when the host reports the resume feature disabled / continuation unavailable.

[me2seeks]

Fix ready for review: #3506 — the host's safeBoundaryResumeEnabled flag defaults off (wired to an env var nothing sets), so turn.resume.query always parks. The PR keeps the plan as the gate and makes /resume render parked reasons as informational notices instead of red errors.