Auto-approve countdown can commit selection after auto-approve toggled off

[0xMink]

Bug description

When a user disables auto-approve while a followup question countdown timer is actively running, the backend setTimeout in Task.ts can still fire and auto-commit a selection even though the user has already disabled auto-approve.

PR #11439 fixed the UI cleanup wiring (passing onFollowUpUnmount to ChatRow so FollowUpSuggest's cleanup sends cancelAutoApproval). However, the backend itself has no independent safeguards:

1. No hard-cancel on toggle-off: When autoApprovalEnabled is toggled off via the webview message handler, the pending setTimeout is not cancelled directly. Cancellation depends entirely on the React cleanup chain firing correctly.

2. No defensive gate in timeout callback: The setTimeout callback executes unconditionally — it does not re-check whether auto-approval is still enabled or whether the ask has been superseded by a newer message.

Scenarios not covered by UI-only fix

• Webview crashes or is disposed before React cleanup fires
• React render timing causes cleanup to run after the timeout fires
• Component unmount order differs from expected sequence
• cancelAutoApproval message is lost or delayed in the postMessage channel

Expected behavior

The backend setTimeout callback should independently verify that auto-approval is still valid before committing a selection, regardless of whether the UI cancellation chain succeeded.

Proposed fix

1. Hard-cancel in webviewMessageHandler: When autoApprovalEnabled is toggled off, call cancelAutoApprovalTimeout() directly on the current task
2. Defensive gate in timeout callback: Re-check autoApprovalEnabled via getState() and verify the ask is not stale before auto-committing
3. Backend regression tests: Cover explicit cancellation, defensive gate, superseded ask, and happy-path scenarios

Builds on top of #11439 (UI cleanup wiring).

[roomote-v0]

I've analyzed this issue and here's my proposed implementation plan:

Problem: When autoApprovalEnabled is toggled off while a followup-question countdown timer is running, the backend setTimeout in Task.ts can still fire and auto-commit a selection. The current code has no hard-cancel on toggle-off and no defensive gate in the timeout callback.

Proposed changes:

1. Hard-cancel in webviewMessageHandler.ts (line ~1553): When autoApprovalEnabled is toggled off (message.bool === false), call provider.getCurrentTask()?.cancelAutoApprovalTimeout() to immediately clear any pending timeout. This is the primary fix -- if the user turns off auto-approve, the backend timeout is killed regardless of UI cleanup.

2. Defensive gate in timeout callback in Task.ts (line ~1530): Before the setTimeout callback commits the auto-approval, re-check two conditions:

   • Re-fetch autoApprovalEnabled from state via this.providerRef.deref()?.getState() and bail out if it is false.
   • Capture askTs at the time the timeout is set, and compare it with this.lastMessageTs when the callback fires. If they differ, the ask has been superseded by a newer message and should not be auto-committed.

   If either check fails, clear the ref and return without committing.

3. Backend regression tests: Add tests in src/core/task/__tests__/ covering:

   • Explicit cancellation via cancelAutoApprovalTimeout() prevents the callback from firing
   • Defensive gate: callback is a no-op when autoApprovalEnabled is false at fire time
   • Defensive gate: callback is a no-op when the ask has been superseded (stale askTs)
   • Happy path: timeout fires and commits when conditions are still valid

This approach provides defense-in-depth: the hard-cancel handles the common toggle-off case, while the defensive gate catches edge cases where cancellation messages are lost or delayed.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.