fix: respect github rate limiting

[j4ys0n]

The problem

On 2026-06-12 a write hit GitHub's secondary rate limit (403, "blocked from content creation"). The reconciler's reaction made it worse: when a content-creating write (auto-merge, auto-submit-review) failed, it was re-issued every ~5–7.5 s with no Retry-After handling and no cap, and the shared error classifier treated GitHub 401/403 as "retryable." So the moment any write started failing, the system hammered the exact endpoints GitHub had just blocked — keeping the limit tripped and risking an integration ban.

How the fix solves it

• Stops the storm at the source. When a GitHub write is blocked, the executor now persists a cooldown (reconcileBackoffUntil) on the run. Every reconcile producer — event-driven, the 30 s PR watcher, the 5 min resync — already no-ops while that field is in the future, so none of them can re-issue the write until the deadline. (Previously only one retry job was delayed; the others bypassed it.)
• Right wait for the right failure. GitHub errors are now typed and classified: secondary limit → honor Retry-After (else ≥60 s, bounded exponential); primary limit → wait for the quota reset; auth/permission → long hold instead of retrying a credential that can't succeed.
• Correct operator signal. GitHub failures now surface GitHub-specific recovery (token/permission/rate-limit guidance) instead of the Claude "OAuth token expired" form, and aren't auto-retried as transient.

Result: at most one write attempt per server-directed (or ≥60 s) interval instead of a continuous loop — i.e. the client now behaves the way GitHub requires, so a transient secondary limit clears on its own rather than self-perpetuating.