Cedar support / pluggable policy backends

[boorad]

Summary

Add Cedar as a second first-class Policy-as-Code (PaC) target alongside the existing Rego/OPA generator, and refactor the generation/output layers so additional engines can plug in without touching the scanner or rule library.

Design memo: docs/CEDAR_SUPPORT.md — read that first.

Why

• Cedar reaches an audience (AWS Verified Permissions, Authzed, Cedar-as-a-library shops) that Rego/OPA does not.
• Cedar's principal/action/resource model maps naturally to some authz patterns we already detect.
• One backend isn't a real test of the abstraction. Two is.

Scope (Phase A — additive, no breaking changes)

• TOML rule format: parallel [rule.<id>.cedar_template] block alongside rego_template
• Finding::cedar_stub: Option<String> added next to rego_stub (backward-compatible JSON)
• New src/cedar/ module (templates, validator using cedar-policy crate, grouping)
• zift extract --engine rego|cedar flag (default rego)
• New MCP tools suggest_policy(finding_id, engine) and validate_policy(content, engine); keep suggest_rego / validate_rego as Rego-pinned aliases for backward compat

Estimated scope: ~250–300 lines of new code, no breaking changes to JSON output or MCP API.

Out of scope (Phase B / later)

• Extracting a PolicyGenerator trait and refactoring extract to be generic over engines (deferred until Phase A has real users)
• Replacing parallel *_stub fields with a policy_outputs: Vec<PolicyOutput> collection (JSON schema break — gate on major version)
• Auto-translating between engines, runtime enforcement, engine-selection heuristics

Non-goals

• Rego → Cedar translation
• Cedar runtime/enforcement
• Shipping more than two engines in this milestone

Risks

See docs/CEDAR_SUPPORT.md for the full table. Headlines:

• Persisted-JSON drift between rego_stub-only and rego_stub + cedar_stub records → keep both fields indefinitely
• MCP tool-name contract → keep suggest_rego / validate_rego as aliases
• --package-prefix is Rego-flavored → rename to --policy-prefix, document Cedar semantics

Open questions

1. Do we require Cedar template parity across all rules before marking Cedar "supported," or ship with partial coverage?
2. Should adding suggest_policy / validate_policy bump the MCP server version string?
3. Is cedar-policy mature enough to be a hard dependency? (review before committing)

Suggested milestone

v0.3 — after v0.2's Python/Go structural support has shipped. Splitting attention between language pluralism and backend pluralism in one milestone is the wrong tradeoff.