docs(governance): policy registry sync and versioning operational guide

[bokelley]

Closes #3140.

Summary

Adds docs/governance/policy-registry-sync.mdx — a new page answering the working group's recurring operational questions about the Policy Registry. Companion to the existing policy-registry.mdx (which is the registry reference); this one is the operations manual.

The headline answer up front: policy_ids[] carries no version qualifier today. Versions resolve at evaluation time (latest-wins). For deterministic text, copy the registry policy into custom_policies[] under a different policy_id (collision with the canonical ID hits the schema's anti-relaxation rule). The audit log + /api/policies/history together provide forensic recovery.

What's covered

• Can I pin a policy version? Direct answer in section 1.
• The inline-copy workaround — JSON example with the renamed-ID requirement explicit.
• Inline policies are additive-only relative to registry-sourced policies — tightened from a previous "additive-only generally" framing per protocol-expert review (a buyer-authored inline policy unrelated to any registry policy is unconstrained — the schema only governs the relationship to registry policies).
• Registry version bumps mid-campaign — three-row table covering plan-via-policy_ids, plan-pinned-via-custom_policies, and completed plans.
• effective_date staged adoption — the four-step pattern, with a note that effective_date handles only the time axis; scope-based staging (channel/jurisdiction subsets) happens at the registry level.
• Sunset behavior — what happens when sunset_date passes, including the publish-both-overlapping-policies pattern for successor regulations.
• WG-shaped FAQ — the actual questions WG members ask: in-flight buys when regulations change, plan revisions and policy refresh, proving to a counterparty which version applied, per-jurisdiction overrides, brand-specific extensions.

Pre-PR review

Ran the full review pipeline:

• ad-tech-protocol-expert: sound-with-caveats. Two Must-Fix items (additive-only framing too broad, renamed-ID requirement implicit-by-example) — addressed in the new file. One follow-up worth filing on its own: policies_evaluated[] schema description says "registry policy IDs" but in practice agents may also record inline IDs. Tracked separately.
• docs-expert: Must-Fix on IA placement (inserted into existing reference page broke its rhythm) — addressed by splitting into the new sibling page. Must-Fix on skim test (headline question buried) — addressed by leading the page with "Can I pin a policy version on my plan?" as the first H2 with a one-sentence direct answer.
• code-reviewer: every schema field, API endpoint, and cross-link verified to resolve. No blockers.
• security-reviewer: nothing ship-blocking. The additive-only invariant is agent-enforced (not just doc-declared); plan_hash makes it provable; the staged-adoption window is the registry's documented behavior, not new attack surface.

Changeset

Empty per the playbook rule for non-protocol changes (this is a descriptive doc that restates existing schema and spec behavior; no schemas, tasks, or API changes).

Test plan

• npm run test:docs-nav — passes
• No stale schemas/latest/ references
• All cross-links resolve to existing files / anchors / API paths
• Both docs.json nav blocks updated

🤖 Generated with Claude Code