Retry/backoff or durable queue for outbound-comment cron failures

The four `atmosphere_*_comment*` cron handlers (`publish_comment`, `update_comment`, `delete_comment`, `delete_comment_record`) call `Publisher::*` methods that can return `WP_Error` for OAuth refresh failures, DPoP nonce mismatches, transport flaps, and PDS 4xx/5xx. `log_cron_error()` writes a breadcrumb but `wp_schedule_single_event` does not retry — failed events are dropped permanently.

A transient PDS outage or expired refresh token leaves an approved comment in a half-published state (TID set, URI absent) until a human edits or re-transitions it. Delete handlers have the mirror divergence — WP state changes, the Bluesky record stays live.

### Suggested shape

Either:

- Reschedule failed publish/update/delete jobs with backoff and a max-attempts cap, or
- Maintain a durable pending-actions queue replayed until success or surfaced in admin UI.

### Origin

Codex adversarial review; deferred from #32.

Start with the four `atmosphere_*_comment*` cron handlers—`publish_comment`, `update_comment`, `delete_comment`, and `delete_comment_record`—then trace their `Publisher::*` calls and `log_cron_error()`. Compare retry/backoff with a durable pending-actions queue, including max attempts or surfaced failures; done means failed publish, update, and delete actions are not permanently dropped and WordPress and Bluesky state can converge.

Written by the indexing model from the issue text.