Propose config fixes for reachability findings

TL;DR: When a Policy violation fires or a reachability query finds an unwanted path, generate a concrete Terraform config fix as a standalone patch instead of only reporting the problem.

User story

As a security engineer, I want a concrete proposed fix for a reachability finding, so I'm not left to manually work out the right config change myself.

Acceptance criteria

• Triggered by either a registered Policy rule violation or an ad hoc reachability query result (network or IAM)
• Produces a targeted config edit (e.g. narrow a CIDR, remove one ingress rule) scoped to the specific offending attribute/block, not the whole resource
• Fix is written as a standalone patch/report artifact — the real tracked .tf file is never modified directly
• Each Policy rule can independently opt in to auto-apply for its own generated fixes (per-rule flag, default off)
• When a rule has auto-apply on, its generated patch is applied via the existing apply! primitive without human review
• When auto-apply is off (default), the patch is left for a human to review and apply

How to verify

Trigger the port-22-open Policy rule against a managed security group. Confirm a patch narrowing/removing the offending ingress rule is produced without the tracked .tf file changing. Flip that rule's auto-apply flag on, re-trigger, and confirm the patch is applied via apply! and the violation clears.

Out of scope

• Auto-fix for unmanaged/Discovered Resources (that's #34's import+destroy path)
• A global auto-apply flag — this is per-rule only

Start by tracing the existing apply! primitive and the port-22-open Policy rule, then inspect how network and IAM reachability findings are represented. Define how targeted Terraform edits become standalone patch/report artifacts and how each rule opts into auto-apply. Done means both Policy and ad hoc findings produce scoped patches without changing tracked .tf files, with per-rule auto-apply behavior verified against the stated scenario.