[Feature Request] Add an explicit token-budget picker for CLI goals

What problem would this solve?

Long-running goals can consume far more tokens than a user intended before they notice diminishing progress. The app-server goal API already has a per-goal token_budget, but Codex CLI does not expose a first-class way to choose that budget when starting a goal.

This is especially important for unattended work. Waiting until a goal finishes and reporting usage afterward is too late: a single long run can consume a substantial share of the user's allowance.

Related reports already describe the impact of unbounded or hard-to-control long-running work: #36273, #34215, and #31812.

Proposed behavior

Add an explicit CLI flow such as:

/goal-budget <objective>

After the objective is submitted, show a keyboard-controlled token-budget slider with bounded presets and a No limit option. Confirming the selection should persist the chosen value through the existing thread/goal/set path before the goal begins.

The existing /goal behavior should remain unchanged, so the new safety boundary is opt-in and backward compatible.

The picker should clearly disclose that an already in-flight model request may complete slightly above the selected boundary.

Scope and limitation

This would be a goal-local token budget, not a strict guarantee that a configured percentage of the account's weekly allowance remains available. A hard weekly reserve would require a server-side quota reservation or pre-request admission-control API; the CLI only receives usage percentages and cannot safely translate them into an exact token allowance.

The goal-local budget is still useful as an immediate safety control because the Goal runtime already stops autonomous continuation when its token budget is reached.

Implementation notes

A focused implementation is prepared on Gekuyme:feat/goal-budget-picker with:

• a dedicated /goal-budget command behind the existing Goals feature gate;
• an accessible keyboard picker (Left/Right, Enter, Esc);
• propagation through GoalDraft to the existing app-server goal token budget;
• snapshot, command-dispatch, and app-server persistence coverage;
• no change to ordinary /goal behavior.

Per the external-contribution policy, this issue is the design proposal. The implementation can be revised or rebased if a maintainer invites the contribution and prefers a different command shape.