Epic: AWS WAF (WAFv2) adapter

[gfargo]

Split out of the #156 roadmap spike (Tier 4: provider epic). Largest of the three — do not start before its dependencies land.

Why it's the biggest lift

AWS WAF is the best long-term fit (it's where a lot of serious WAF config lives) and simultaneously the worst fit for doorman's current model. Four independent structural mismatches:

1. Recursive statement trees. AndStatement/OrStatement/NotStatement wrapping leaf matchers, nestable to arbitrary depth. UnifiedRule.conditions[] + one-level group cannot represent this. → Model: recursive condition trees (UnifiedRule.conditions cannot express nested boolean logic) #184
2. Scope + multi-resource attachment. A WebACL lives in CLOUDFRONT or REGIONAL scope, is region-bound, and attaches to N resource ARNs. → Model: multi-resource / multi-region targeting (UnifiedConfig assumes one provider = one target) #185
3. Mandatory optimistic concurrency. Every write requires a LockToken fetched from the current state. syncRules has no concept of this; a stale token means the write is rejected and must be retried against refreshed state.
4. Managed rule groups are central. AWS Managed Rules + Marketplace vendor rulesets are the bulk of a typical WebACL, with per-rule overrides being standard practice. → Model: managed rule group support (config surface + provider plumbing) #183

Also worth noting: WAFv2 statement types are richer than doorman's condition model in kind, not just structure — SqliMatchStatement, XssMatchStatement, LabelMatchStatement, RateBasedStatement with its own nested scope-down statement. Several have no unified equivalent at all and need either new UnifiedCondition field types or an explicit unsupported-feature path.

Dependencies — all required

• Groundwork: open the ProviderType union and drive provider lists from the registry #181 — open ProviderType
• Groundwork: generalize per-provider credentials and the providers config block #182 — generalize credentials (AWS adds accessKeyId/secretAccessKey/sessionToken/region/scope/webAclArn; the flat-field approach breaks down completely here)
• Model: recursive condition trees (UnifiedRule.conditions cannot express nested boolean logic) #184 — recursive condition trees
• Model: multi-resource / multi-region targeting (UnifiedConfig assumes one provider = one target) #185 — multi-resource / multi-region targeting
• Model: managed rule group support (config surface + provider plumbing) #183 — managed rule groups
• UnifiedRule.priority affects diffing but never affects rule evaluation order #179 — rule ordering (WAFv2 uses explicit numeric Priority)

That's effectively the entire groundwork backlog. Recommend landing Fastly (#186) first to validate the interface generalizes at all before committing to this.

Additional scope beyond a normal adapter

• LockToken handling threaded through the sync path (fetch-then-write with retry-on-stale)
• IAM permission preflight — the CloudflareSetupVerifier pattern is a good precedent; AWS failure modes are notoriously opaque without it
• Deciding whether doorman manages WebACL creation or only rules within an existing WebACL (strongly recommend the latter initially — WebACL creation drags in scope/region/association concerns)

Acceptance criteria

• All 8 commands work with no command-layer changes
• Nested statement trees round-trip losslessly
• A rule using a WAFv2 statement type doorman can't represent fails explicitly rather than syncing something subtly different
• Concurrent-modification (stale LockToken) is handled with a clear retry or a clear error, never a silent lost update