fix(macapp): acknowledge run-control failures and preserve pending user input

[dennisonbertram]

Parent: #991

Summary

High-stakes run-control requests are fire-and-forget. Cancel, approve, deny, and answer use try? or otherwise discard failures. answer() removes pendingQuestions before the server acknowledges the response, and the form considers an answer complete based only on dictionary key count.

Evidence

• macapp/Sources/GoCodeUI/RunSession.swift:128-149 — cancel/approve/deny swallow request failures.
• RunSession.swift:169-173 — pending questions are cleared before an acknowledged answer and submission errors are swallowed.
• macapp/Sources/GoCodeUI/ChatView.swift:813-855 — Send is enabled by answers.count; typing then deleting a required freeform answer leaves an empty value counted as complete.
• The first failed cancel sets cancelRequested = true; the next click can abandon the stream locally while the server run continues.

Impact

The GUI can claim or imply that a decision was delivered when it was not. A pending question can disappear permanently on a transient failure, and a failed cooperative stop can turn the next click into a local-only force stop.

Scope

• Introduce explicit pending/succeeded/failed action state for cancel, approve, deny, plan approval, and user answers.
• Clear a pending question only after the server acknowledges the answer.
• Validate trimmed non-empty required answers; preserve entered answers and focus on error.
• Reset cancel escalation when the cooperative request fails.
• Surface retryable errors inline at the action that failed and announce them accessibly.
• Prevent duplicate submissions while a request is in flight.

Tests first

• Stub-client tests for success, transport failure, structured server failure, retry, and duplicate-click suppression for each action family.
• Regression: an answer failure keeps pendingQuestions and the answer draft.
• Regression: an erased-to-empty freeform answer does not enable Send.
• Regression: failed first cancel does not arm local force-cancel.

Acceptance criteria

• No run-control endpoint failure is swallowed.
• Pending questions remain visible and editable until acknowledged.
• Empty required answers cannot be sent.
• Action controls show in-flight state and reject duplicate requests.
• Failure messages give a retry path and are VoiceOver-announced.
• swift test, Swift build, formatting, strict format lint, and a live daemon control smoke pass.

[dennisonbertram]

Repair scope for PR #1021 after independent review:

• Add request-generation ownership for answers so a stale completion cannot clear a newer in-flight guard.
• Add generation/run validation for pending-question fetches.
• Add single-flight approve/deny/steer state, duplicate suppression, and steering draft restoration on failure.
• Keep pending questions and entered input until server acknowledgement.

All fixes will preserve exact red/green evidence and remain scoped to native RunSession/UI behavior.

[dennisonbertram]

PR #1021 repair is pushed at 575b670938821f9db8b5bb096e3956753b0f0e25. #994 now has generation/run validation for pending-question fetches, answer ownership across reset, and single-flight acknowledged approve/deny/steer with non-destructive draft restoration. Focused RunControl coverage and full Swift (303 tests / 55 suites) pass.

[dennisonbertram]

PR #1021 exact head afa92d20c7ec10438cbbde4550bb8886e2b0465a closes the final pending-question ownership edge found in review: AskUserView identity now follows prompt.callID, so answer state cannot carry into a newer server prompt with the same question shape. The source-reachability regression was observed red then green. Focused review set passes 13 tests / 3 suites; full Swift passes 308 tests / 55 suites.