Make actions reviewable, permissioned and verifiable

Priority: P0 (foundation — do first).

An assistant needs clear authority and evidence of what it actually did. Reassuring prose is not a receipt.

Acceptance criteria

• Present permissions as services/actions and distinguish read, draft, send, change, purchase and delete capabilities.
• Preserve existing user grants and require review for consequential actions where authority is absent; avoid repetitive approval for already-authorised routine work.
• Show the concrete recipient, content and effect before a required approval.
• After execution return receipts or source records stating exactly what succeeded, partially succeeded or failed.
• Provide undo or a compensating action where supported, and explain irreversible effects accurately.
• Test permission revocation, forged identity, changed action after approval, duplicate execution and ambiguous provider outcomes.

Dependencies and boundaries

Depends on identity enforcement in #1443 and retry semantics in #1513. Reuse existing authorization and audit mechanisms.

Implementation approach

Audit current main first: some foundations and recent fixes already exist. Close remaining user-visible gaps and preserve working behaviour. This issue records the personal-assistant product backlog, not a claim that every underlying capability is absent. Add focused regression coverage for the behaviour changed.

Start by auditing the current main branch, then review the identity enforcement dependency in #1443, retry semantics in #1513, and the existing authorization and audit mechanisms. Identify the remaining user-visible gaps and add focused regression coverage for changed behavior. Done means permissions, approvals, receipts, undo or compensating actions, and the listed edge cases are covered without breaking working behavior.