feat: define approval/idempotency/audit/rescan gate for agent-driven remediation

What problem does this solve?

Any future agent-proposed remediation (running a playbooks/cli/*.sh script against a real
subscription) has real blast radius — a retry or a bad proposal can change customer
infrastructure. Phase one should be proposal-only, but the execution gate needs to be specified
now so no track starts building an execution loop without it already in place.

Describe the solution

• Typed allowlist of playbooks eligible for any future automated execution (starts empty).
• Mandatory human approval step before any execution.
• Idempotency guarantee: a retried action must never execute twice.
• Full audit log of proposal → approval → execution → rescan-verification.
• Rescan-based verification: a remediation is "pending verification," not "done," until a rescan
  confirms the finding cleared; failed verification stays open, not silently closed.
• Phase one ships proposal generation only — no execution path merges until this gate exists in
  code, not just as a design doc.

Alternatives considered

Build the proposal UI now and add the safety gate right before the first real execution ships —
rejected; it has to exist before any execution-adjacent code is written.

Additional context

Exit test: retries never execute twice; failed verification remains open.

Start by reviewing the playbooks/cli/*.sh remediation entry points and the existing proposal-generation flow. Define the execution gate around the stated requirements: an empty typed allowlist, human approval, retry-safe idempotency, complete audit history, and rescan-based verification. Done means phase one remains proposal-only and failed verification stays open.