fix(recovery): revalidate physical recovery profile before serialization

[seonghobae]

Protected-main data-integrity defect — current authority

Protected main is exact 5913c4bad79d6bc29d7cc1c624abb7db2ea6a77c. Protected serialization remains pre-repair authority until the active Draft reaches normal protected integration.

PostgresPhysicalRecoveryProfile.as_dict() / to_json() must not trust construction-time validation after caller-visible frozen/slotted state has been modified through low-level attribute mutation/deletion. The bounded repair snapshots every required field once, normalizes deleted-slot failure through PostgresPhysicalRecoveryError, revalidates the complete local snapshot through the same constructor contract, and serializes only those validated locals.

The repair preserves deterministic compact JSON, the 2048-byte parser ceiling, exact primitive/duplicate-key rules, physical/PITR/WAL consistency, isolated-target requirement, and hard-coded package_capability_claim=False. Caller-selected RPO/RTO values remain objectives rather than achieved capability. This seam does not establish backup execution, WAL continuity/replay, provenance, restore usability, HA/DR, or deployment RPO/RTO.

Canonical implementation lane — Draft #272

Fresh live topology:

• dependency root/base test(recovery): cover stale evidence registry cleanup #233: 01d231fde23b82e2ced258d7bfcb4721ed75706d;
• branch: fix/physical-recovery-profile-serialization-b84f0c9;
• exact current head: b83d1ecd61ba2ac5adb67c372fbca848f05bb56b;
• compare from exact test(recovery): cover stale evidence registry cleanup #233: 5 ahead / 0 behind, merge base exactly test(recovery): cover stale evidence registry cleanup #233;
• effective delta: exactly pg_llm_batch/postgres_physical_recovery.py and tests/test_postgres_physical_recovery_mutation.py;
• state: Draft/open/mechanically mergeable;
• fresh formal reviews: none;
• fresh inline review threads: none;
• qualifying independent APPROVED: absent.

The previous issue snapshot that named protected b84f0c9..., historical #233 5951b7a..., and #272 head d86b019... is lineage only. The current #272 head is already the ordinary two-parent, non-force current-root reconciliation: prior #272 is preserved as first parent, exact current #233 as second parent, and the resulting tree re-applies only the two owned blobs on current #233. No force push, destructive rebase, protected-main mutation, self-approval, or gate weakening was used.

Exact-current branch evidence

For exact #272 b83d1ecd61ba2ac5adb67c372fbca848f05bb56b:

• CI 34474911250: completed / success;
• Release Acceptance 34474911241: completed / success;
• formal reviews: none;
• inline review threads: none.

These are branch-candidate results only. Absence of review is not approval, and predecessor checks/reviews do not transfer across ancestry movement.

Integration boundary

#233 must integrate first through live governance. Mutable central workflow/review state is owned by #244 and must be re-read at integration time rather than copied into this focused issue.

After #233 reaches protected main, reconcile the same two-file #272 slice ordinarily/non-force onto the resulting exact protected ancestry and reacquire every then-live exact-final-head/current-base supported-Python, exact owned production statement/branch coverage, public-docstring, PostgreSQL/container where applicable, security/SAST/model-backed, package/SBOM/provenance/reproducibility/release, formal-review, and thread-resolution gate.

Do not self-approve, synthesize status, copy central workflow authority locally, weaken protection, use routine administrator bypass, force-push, destructively rebase, or transfer predecessor evidence.

Close only after this serialization repair is normally integrated and immutable protected-head release evidence is complete. Draft GREEN is not shipped truth.

Refs #204, #233, #244, #271, #272.