Surface Post::META_ORPHAN_RECORDS in admin / Site Health

[kraftbj]

Background

Publisher::persist_orphan_records() and Publisher::rewrite_thread()'s rewrite-phase manifest write entries to Post::META_ORPHAN_RECORDS whenever a thread publish or rewrite fails and the compensating delete also fails. The post meta is the source of truth for what the PDS still holds that the WP side considers gone.

Today it is write-only — no UI, Site Health check, admin notice, or cron consumes it. An operator only finds out by querying post meta directly.

Proposal

Surface the manifest in at least one of:

• A Site Health check that flags how many posts have entries in META_ORPHAN_RECORDS and links to a list view.
• An admin notice on the post edit screen for an affected post, with a "retry cleanup" or "mark resolved" action.
• A WP-CLI subcommand (wp atmosphere orphans list/retry/clear) for site administrators who prefer the terminal.

Bonus: a scheduled WP-Cron job that retries the compensating delete for orphan entries with a backoff, removing entries from the manifest once the PDS reports the records as gone.

Constraints

• Manifest is capped at 10 entries per post (most-recent-wins) to bound meta_value size — any consumer should still tolerate that cap.
• Each entry has a stamp (ISO8601), bsky_records (uri/cid/tid triples), doc_rkey, original_error, rollback_error. The rewrite_thread flow adds a phase: 'rewrite' marker.
• Don't expose the raw URIs / CIDs to non-admins — these are write-target identifiers on the PDS.

Context

Tracked here so the publish/rewrite paths in #34 can ship without bundling the operator UI. Linked from a TODO in Publisher::persist_orphan_records().