Make `--max-autopilot-continues` persistable in settings and adjustable mid-session via /limits

Describe the feature or problem you'd like to solve

--max-autopilot-continues (default 5) is the only control over how long autopilot keeps going, but it is launch-flag-only: there is no settings.json key, no environment variable, and no way to change it once a session has started. Long-running autopilot work therefore stops at 5 continuations unless you remember the flag at launch — and when it does stop, there is no way to raise it without restarting the CLI and losing the session.

Proposed solution

Two related changes, either of which is useful on its own:

1. A persistable setting (maxAutopilotContinues)

Add a settings.json / config.json key so the default can be set once, with --max-autopilot-continues still overriding it per-invocation.

Today the value is registered in the arg parser with a hardcoded default and read only from the parsed CLI options object:

new Option("--max-autopilot-continues <count>", "Maximum number of continuation messages in autopilot mode")
  .default(5)

Confirmed absent from copilot help config (no settings key) and copilot help environment (no env var). The only workaround is shadowing the launcher with a shell wrapper that injects the flag:

function copilot {
    $copilotArgs = @($args)
    if (-not ($copilotArgs | Where-Object { $_ -like '--max-autopilot-continues*' })) {
        $copilotArgs += @('--max-autopilot-continues', 50)
    }
    & $RealCopilotShim @copilotArgs
}

That works, but it is per-shell (breaks if you launch from a different shell), invisible to anyone reading their config, and easy to forget on a new machine.

This is the same "hardcoded constant → user-settable key" shape as #1688 (configurable auto-compaction threshold), and #3977 established the precedent of adding a settings.json key for autopilot behavior — that one shipped as stayInAutopilot, which persists the mode but not the continuation cap.

2. Runtime adjustment via /limits

Make the cap changeable mid-session, e.g. /limits set max-autopilot-continues <n>.

This is the more valuable half. The value is currently read once at session construction and threaded through to the continuation decision, so when autopilot halts at the limit the session is stuck — the only recovery is restarting and losing accumulated context.

/limits is already the natural home for this: it lets you raise max-ai-credits live, and the limit-reached message already tells you to "increase or unset the session limit before trying again." Hitting the autopilot cap should offer the same recovery, ideally with an inline prompt to extend when the limit is reached.

Example prompts or workflows

1. Long refactor — /plan a large migration, choose "Accept plan and build on autopilot", walk away. It stops after 5 continuations with most todos still pending; restarting to pass a flag discards the plan context.
2. Set once, forget — put "maxAutopilotContinues": 50 in settings.json alongside stayInAutopilot, instead of maintaining a shell wrapper on every machine.
3. Recover in place — autopilot stops at the cap with 3 todos left; run /limits set max-autopilot-continues 40 and resume, rather than restarting.
4. Fleet runs — /fleet orchestration dispatches subagents across many todos and legitimately needs more continuations than a single-file edit; today both share the same default of 5.
5. Cost control that actually fits — raise the continuation cap while relying on --max-ai-credits as the real spend guardrail, instead of using a low continuation count as a proxy for budget.

Additional context

• Copilot CLI 1.0.79, Windows 11, PowerShell 7
• Related: #1688 (configurable auto-compaction threshold — same shape), #3977 (closed; added stayInAutopilot, adjacent but different knob), #4210 (configurable autopilot retry count), #3352 (/config editor — would surface this key once it exists)
• Precedent for this class of request shipping: #2520, #3026, #2582
• Note that raising the cap safely depends on --max-ai-credits, which is itself already session-settable via /limits — so the two controls are currently inconsistent in how they can be adjusted.

Start with the arg parser registration for --max-autopilot-continues and the settings.json/config.json loading path. Then trace the /limits handling and the session construction path where the value reaches the autopilot continuation decision. Done means the setting has the stated precedence, /limits can change the active cap, and the documented workflows work without restarting the CLI.