D2.2c Content sync adoption: docs, FAQ and podwiki, retire the staged pipeline

User direction 2026-09-12: continue the community-base unification of ai-shipping-labs and dtc-website. This issue mirrors plan item D2.2c from community-base docs/plan/phase-2.md; community-base docs/plan/STATUS.md stays authoritative for live status across all four repositories.

Normative references

• community-base docs/plan/phase-2.md, section "D2.2c Content sync adoption: docs, FAQ and podwiki, retire the staged pipeline" - the implementation contract; follow its steps literally.
• community-base docs/plan/STATUS.md, row D2.2c - canonical status.
• #379 (D2.2a) - records the old pipeline's per-type counts that this part's verification compares against.
• _docs/specs/01-platform-architecture.md "Content refresh" section and _docs/specs/03-github-content-and-people.md; _docs/specs/open-decisions.md decision 1 (direct upsert, decided in #226).
• _docs/PROCESS.md, _docs/ci/change-selective-ci.md, playbook P14 (migration rehearsal with counts).

Scope

1. Write site parsers for docs, FAQ and podwiki and register them with the package engine, per the parser contract used in D2.2a.
2. Delete content_sync/, the ContentRelease, ActiveContentPath and FrozenReleaseChild models and the content/services.py release graph; route resolution reads the synced rows directly with the existing draft filter.
3. Storage-drop migrations for the retired staged-pipeline tables, rehearsed on a development copy with counts recorded (P14).

Non-goals

• Events: excluded from sync (Phase 4 makes them database authored).
• Public URL, route or SEO shape changes; the compatibility suite governs.
• Package or Relay changes; the pinned published release is used as-is.

Dependencies and blocked work

• Depends on #382 (D2.2b). Do not start while it is open.
• Blocked in turn on #379 (D2.2a) through that dependency chain.

Tracker reconciliation

• The pre-plan direct-sync epic #38 and its slices #272-#278 overlap this part: #276 (public reads to direct-sync authority) and #278 (retire staged ContentRelease behavior and reconcile specifications) describe the same retirement this issue implements via the package engine.
• #278 is retained needs grooming by its own PM note and is not modified by this filing. When this issue is picked up, the owner should reconcile or supersede the epic slices against the plan instead of running both decompositions.

Acceptance criteria

• docs, FAQ and podwiki parsers are registered with the package engine per the parser contract
• uv run python manage.py sync_content --from-disk <checkout> on a fresh database produces per-type counts equal to the old pipeline's counts recorded in #379 for every adopted type
• content_sync/, ContentRelease, ActiveContentPath, FrozenReleaseChild and the content/services.py release graph are removed; route resolution reads the synced rows directly with the existing draft filter
• storage-drop migrations are rehearsed on a development copy with counts recorded (P14); uv run python manage.py makemigrations --check --dry-run is clean
• uv run pytest content -q passes
• the public URL compatibility suite (_docs/compatibility/) passes
• _docs/specs/01-platform-architecture.md "Content refresh" section is rewritten to the direct-upsert workflow

Scenarios

• Django/integration: fresh-database sync with per-type count equality; migration rehearsal on a development copy; retired-import inventory empty except immutable migrations and intentional historical docs.
• Browser: not_applicable only when the ci/ownership.json graph confirms no render impact; the compatibility suite is the render contract.
• Repository/operations: engineer generates the versioned verification plan (make verification-plan VERIFY_ISSUE=<this issue>); tester recomputes it from the frozen base/head; local --no-ff merge; on-call observes CI.

Rollback

• Before the cutover landing, reverting is trivial; the staged pipeline still serves the remaining types.
• The storage drop is one-way after the migration; rehearse on a development copy and record counts before landing (P14).

Do not start until #382 is closed. First read community-base docs/plan/phase-2.md and docs/plan/STATUS.md, then review the parser contract from #379, _docs/specs/01-platform-architecture.md, and _docs/specs/03-github-content-and-people.md. Use manage.py sync_content --from-disk and pytest content -q as the main checks; done means the parser counts match #379, the staged pipeline is retired, migrations are rehearsed, and the compatibility suite passes.