feat(planning): choose task attempts before execution

[shyamsridhar123]

Operators can choose the total task-attempt allowance (1–3) before execution. Planning, previews, Factory policy, CLI, MCP, ACP and A2A share the existing bounded planner behavior. Later revisions cannot increase that allowance or reset spending.

The native verifier-seal correction also allows a failed checkpoint-derived correction to use its remaining authorized attempt while preserving the original source, grants and history. The optional test-context publication policy is recorded before claim; the driver itself never publishes.

Validation completed September 12, 2026:

• Recovery workspace: 540 Rust tests passed, 323 deliberately ignored; workspace/all-target Clippy and formatting passed.
• 122 distinct actual-migration SQLx cases passed against isolated test databases.
• 250 frontend tests, web build/lint and all 41 migration checks passed.
• The controller dry-run test now strictly checks the planned-task preview, including the default two-attempt allowance. Its exact assertion passed against the native preflight endpoint without changing retained records; the local parallel Windows runner suite passed 213 tests with one deliberately ignored.
• Public 1 → 1 → 2 → 3 sequence passed with the original four checks, independent development-principal review, unchanged history/spend and zero remaining attempts.
• A separately preauthorized case passed native publication through local Git and the fake-GitHub boundary. Duplicate invocation produced only one PR record and one Project edit.
• Actual browser completed/failed/published result views and mobile layout verified. Automated browser file saving was canceled and is not counted as a pass; authorized API and native-publisher downloads passed exact byte checks.

Source-bound acceptance report and retained limits.

Full hosted CI passed all six jobs on 5c3c895108b3eabc416b4dcc0f39765ed9f820e7: run 34707975467. The earlier failed run remains retained.

This completes the earlier runtime draft gate. Protocol fixtures are not vendor inference or production identity. Existing hosted checks retain their own head-specific status. Part of the dependent recovery stack above #227; main's update restriction remains a separate integration constraint.

Refs #224, #221.

[shyamsridhar123]

September 10 QA progress: the explicitly approved isolated API/runner/UI now starts successfully on 19084/16084. The earlier host-startup hold is resolved; the manual main instance on 18962/15491 remains healthy and untouched.

The native public drill is now executing. Its first run found one driver defect: it omitted the existing controller's post-launch Factory running transition. That existing actor/token/version-bound API step is now included locally. All failed receipts and worktrees are retained; no state/counter repair or reset was performed.

The next runs reached genuine initial suspension, provider-free failed checkpoint verification and a provider correction's native verification_failed. They exposed a real #221 compatibility defect: historical validation requires a top-level head_commit on the earlier verifier's preservation event, but the native verifier emits its exact authorized fingerprint only after both fingerprint/HEAD checks and does not emit that redundant field. The retained request still has the authorized HEAD.

Precision correction to the initial triage: before a new latest-source revision, this history error is caught and displayed as unavailable correction; after that revision the same error propagates as historical request no longer matches its native source seal. These are two symptoms of the same product defect, not a separate availability-assertion defect. The original positive availability assertion is restored; a new current revision remains mandatory for actual admission.

A narrowly scoped compatibility fix and regression coverage are in progress. This is not a passing second-correction/application claim yet; draft status and open issues remain. No vendor inference, GitHub Actions dependency, merge, auto-merge or protection change.

[shyamsridhar123]

The user gave fresh go-ahead for the QA-only restart. The same owned Stop/Start operation was retried once and the host again rejected process creation before PowerShell executed. Authorization is clear; another generic approval prompt is not a useful remedy. No alternate launcher, delegated workaround, process stop or manual-app substitution was attempted. The original QA build remains running and this patch's full runtime acceptance remains unproven.

Independent queue work continued: #199 and #205 were audited against merged main b28fd4d / #228, closed as completed, and verified Done in Project3. #226 received a commit-bound changes-requested review after six CLI tests passed but both declared preservation hashes failed against the actual published Git blobs; the fresh LF/CRLF mismatch is also recorded under #82. These are separate outcomes, not substitutes for #229 acceptance. No PR was merged and the manual application remains untouched.