[Fix] stabilize exec approval state handling

[samzong]

Summary

Stabilize the desktop exec approval flow so pending approvals stay tied to the right task and do not disappear when resolve requests fail.

Type of change

• [Fix] bug fix
• [Feat] new feature
• [UI] UI or UX change
• [Docs] documentation-only change
• [Refactor] internal cleanup
• [Build] CI, packaging, or tooling change
• [Chore] maintenance

Why is this needed?

Operators should not lose approval state because a resolve call failed, and approval requests should surface on the correct task.

What changed?

• tightened exec approval typing in shared protocol and domain types
• updated the main/preload bridge to use the typed resolve params
• kept pending approvals task-aware in the renderer store and preserved them on resolve failure
• added store tests for task association and resolve success/failure behavior

Architecture impact

• Owning layer: shared / main / preload / renderer
• Cross-layer impact: yes; the shared approval contract now flows through the existing main -> preload -> renderer boundary
• Invariants touched from docs/architecture-invariants.md: shared protocol ownership, preload-only renderer boundary, explicit task routing by sessionKey
• Why those invariants remain protected: protocol types stay in shared, renderer access still goes through window.clawwork, and task association is still derived from sessionKey

Linked issues

Closes #

Validation

• pnpm lint
• pnpm test
• pnpm build
• Manual smoke test
• Not run

Commands, screenshots, or notes:

pnpm check

Screenshots or recordings

No screenshots. This change updates approval state handling and test coverage.

Release note

• User-facing change. Release note is included below.
• No user-facing change. Release note is NONE.

Improve desktop exec approval handling so pending approvals stay associated with the correct task and remain visible if approval resolution fails.

Checklist

• The PR title uses at least one approved prefix: [Feat], [Fix], [UI], [Docs], [Refactor], [Build], or [Chore]
• The summary explains both what changed and why
• Validation reflects the commands actually run for this PR
• Architecture impact is described and references any touched invariants
• Cross-layer changes are explicitly justified
• The release note block is accurate

[github-actions]

Hi @samzong,
Thanks for your pull request!
If the PR is ready, use the /auto-cc command to assign Reviewer to Review.
We will review it shortly.

Details

Instructions for interacting with me using comments are available here.
If you have questions or suggestions related to my behavior, please file an issue against the gh-ci-bot repository.