Model: multi-resource / multi-region targeting (UnifiedConfig assumes one provider = one target)

[gfargo]

Split out of the #156 roadmap spike (Tier 3: model extension). Blocks AWS WAF and GCP Cloud Armor.

Problem

UnifiedConfig assumes a single provider instance targets a single resource:

// src/lib/types/common.ts
export interface ProvidersConfig {
  vercel?: { projectId?: string; teamId?: string }
  cloudflare?: { zoneId?: string; accountId?: string }
}

One zone, one project. That's correct for Cloudflare and Vercel. It does not fit:

• AWS WAF — a WebACL exists in a scope (CLOUDFRONT or REGIONAL), is region-bound for REGIONAL, and attaches to N resource ARNs (ALBs, API Gateway stages, AppSync APIs). Managing "the same ruleset across 3 regions and 6 load balancers" is the normal case, not an edge case.
• GCP Cloud Armor — a security policy attaches to N backend services.

Every command also assumes one target implicitly: sync writes to one place, diff compares against one place, status reports one version.

Open design questions (resolve before implementing)

1. One config, N targets — or N configs? Does a single .doorman.json describe a ruleset applied to many resources, or does doorman stay one-config-one-target and leave fan-out to the user/CI? The former is much more useful and much more work.
2. Partial failure semantics. If a sync succeeds on 4 of 6 targets, what does SyncResult report? The existing errors[]/success shape (from fix: stop Vercel sync from corrupting rules and discarding real errors #166) is a reasonable starting point but was designed for per-rule failures, not per-target.
3. Drift across targets. If targets diverge (someone hand-edited one), what do diff/status show? Per-target output, or a merged view with divergence called out?
4. Does version still mean anything? SyncResult.version / metadata.version assume one authoritative remote version.

Recommendation

Do not build this speculatively. It's the single largest interface change in the #156 roadmap and its right shape depends heavily on which provider lands first. Sequence it with the AWS WAF or GCP epic — whichever is prioritized — rather than ahead of both. Filed now so the constraint is visible when scoping those.

If Fastly is chosen as the first third adapter (recommended in the roadmap — it's structured-JSON and roughly Vercel-sized), this issue is not on the critical path.

Acceptance criteria

To be defined once question 1 is settled. At minimum: a config can target multiple resources, and sync/diff/status report per-target outcomes without pretending partial success is total success.

[gfargo]

Scoping note while starting the GCP epic (#187): this issue's premise doesn't actually apply to Cloud Armor. I verified against the real GCP API/Terraform docs — a google_compute_security_policy's rule content is fully independent of which backend services reference it; attachment is a one-directional pointer living on the backend service side (securityPolicy field, set via a separate setSecurityPolicy call), not something the policy resource itself tracks or requires. Full details in the comment on #187.

So Cloud Armor fits doorman's existing one-config-one-target model cleanly (one security policy per config, same shape as one Vercel project or one Cloudflare zone) — the GCP epic won't need this issue resolved, and isn't the epic that should settle its open design questions.

Leaving this open and unchanged for AWS WAF, where it's still real: a WebACL's association with N resource ARNs is part of the WebACL API surface itself (AssociateWebACL/ListResourcesForWebACL), not a separate resource-side pointer — a materially different shape from Cloud Armor's. Whoever picks up #188 will need to actually answer this issue's four open questions.