Surface Post::META_ORPHAN_RECORDS in admin / Site Health

## 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()`.