docs(reporting): document upgrade boundaries and guarded release steps

[bokelley]

Reliable Reporting deployments need a documented upgrade and release path that reflects the installed components. This PR brings together the nine historical comparison boundaries, account-qualified configuration identity, rc.6 live versus offline historical schemas, feature tiers, migration and activation limits, and guarded release procedures.

The service guidance distinguishes durable committed rows from source recovery: exact revision reads use rows retained in the PostgreSQL ledger. Default in-memory staging and replay seals affect interrupted acquisition and sealed-result replay across restart; losing those stores does not remove already committed ledger rows. The PostgreSQL factory still requires appropriate durable source implementations and coordinated worker ownership for production recovery.

File	Resulting guidance
docs/reporting-release-notes.md	Central upgrade notes covering all nine exact historical boundaries, generation-key migration, supported tiers, activation and operational limits; correctly separates committed-row retention from acquisition/seal recovery.
docs/reliable-reporting-service.md	Connects service adoption to upgrade/production guidance and explains the PostgreSQL ledger versus default memory staging/seal durability boundary.
docs/reporting-production.md	Points production operators to the upgrade boundaries and clarifies configured composition and readiness.
MIGRATION_v7_to_v8.md	Directs existing integrations to the reporting migration and release notes.
RELEASING.md	Replaces obsolete automatic-publication/token-upload instructions with the guarded proposal, exact-main acceptance, publish and registry-verification sequence.
docs/releasing.md	Connects the detailed guarded runbook to the release overview and required reporting upgrade notes.

Exact candidate: head 773e8d2f05fa2c41f0084db5885762cf00a34216, tree 86e23093f07a763aa0f543d7cba01ba907f6b2af, immediate parent f405d7944657254f89429df9a0140a5ca7929b7e, accepted main base 940c95e0c2d93758ed334b3edff59cbe933362d4. The complete PR changes six Markdown files. The final child changes only the two prepared durability explanations; no runtime, workflow, version or release-setting changes are included.

Validation on this candidate:

• All 29 local links and heading anchors across the six documents pass, including Git-tree checks for sparse-checkout targets. All nine comparison commits are distinct ancestors of the accepted base.
• Source verification against the accepted base confirms that service exact reads call read_revision_rows, PostgreSQL commits persist reporting_revision_rows, and exact reads query those durable rows. Adapter defaults and sealed-result replay were checked separately.
• Applicable ordinary documentation and commit-message hooks pass without bypasses or candidate-byte changes.
• Fresh pinned Gitleaks 8.30.1 scanning covers all six complete current files (76,843 bytes) and both commits, including full merge-parent additions from the accepted base (16,655 bytes): zero matches or incomplete-input issues. Newly generated positive/negative controls pass, including a synthetic match beyond 8.4 MB with an inline allow comment. No repository ignore/baseline or input-size cap is used; upstream value allowlists and pattern-detection limits remain. Local scan report SHA256: c18d14445bd70590b04fcdbff5d368088560ed051c42d225fe7fa2345b245415.

The original f405d794 CI was captured before the correction: six workflows, 47 jobs, 49 checks and one status context all succeeded, with no pending run. Those results are historical evidence for that parent only. New-head CI, repository secret checks, independent review and required acceptance remain pending; the local scan is not a substitute for them.

These notes are prepared for the next release proposal. Full service acceptance, installed Python/TypeScript interoperability, guarded publication and registry verification remain separate gates. No package or release acceptance is claimed by this documentation PR. Refs #1172, #1199.

[aao-secretariat]

Ladon verdict: Approve

Approve — docs-only PR, no blocking findings.

This PR touches 6 documentation files (MIGRATION_v7_to_v8.md, RELEASING.md, docs/releasing.md, docs/reliable-reporting-service.md, docs/reporting-production.md, docs/reporting-release-notes.md) with a single docs(reporting): commit. No runtime, workflow, version, or release-setting changes.

Reviewer verified internal links/anchors resolve, the generation_key migration note matches ReportingConfigurationGenerationKey in src/adcp/reporting/ledger/models.py, and the RELEASING.md rewrite correctly retires the legacy Release-Please/PyPI-token path in favor of Trusted Publishing.

Decision table walkthrough:

• Row 1 (critical/high): no findings.
• Row 2 (gated_paths + not APPROVED): gated_paths is false — does not fire.
• Rows 3–5 (high_risk): high_risk is false.
• Row 6 (sticky escalate): no prior decision.
• Row 7 (no-auto-approve team): no team match.
• Row 8 (≥3 medium): zero medium findings.
• Row 9: approve.

Note: review_decision is REVIEW_REQUIRED, but since gated_paths is false, row 2 does not apply and this does not block approval.

[aao-secretariat]

Ladon verdict: Approve

Approve — docs-only clarification, no findings.

This subsequent pass on PR #1216 changes only Markdown docs (MIGRATION_v7_to_v8.md, RELEASING.md, docs/releasing.md, docs/reliable-reporting-service.md, docs/reporting-production.md, docs/reporting-release-notes.md). The delta since the prior approve is a prose-only clarification distinguishing durable committed ledger rows from in-memory staging/seal recovery, verified accurate against source (read_revision_rows at service.py:737 reading the durable reporting_revision_rows table). No code, wire-shape, or public-surface changes; no credentials/import-layering/generated-code concerns apply.

Decision table: no critical/high/medium findings (row 1 n/a); gated_paths=false (row 2 n/a); high_risk=false with no deletions (rows 3/5 n/a); no medium data-loss/schema/infra findings (row 4 n/a); prior decision was approve, not escalate (row 6 n/a); no no-auto-approve team match (row 7 n/a); fewer than three medium findings (row 8 n/a). Falls through to row 9 → approve. The docs touched here are not adopter-facing build-path docs (SKILL.md/AGENTS.md/llms.txt/README.md), so the largest-file/behavior-affecting docs rules do not apply.