feat: retry-with-backoff for the parallel publish path

[ianpittwood]

Stacked on #641. Part of splitting #599 (parallelize + retry + unify oras/soci into imagetools) into smaller, independently-reviewable pieces.

What & why

Retry-with-backoff for transient registry errors (RetryPolicy/retry_on_transient in posit_bakery/retry.py) already covered the riskiest phases of the parallel publish path introduced in #641 — index-create and the SOCI pull step, both carried forward from a pre-existing GHCR-flakiness fix. Two gaps remained:

• Stage 3 (verify) had no retry. OrasIndexVerifyWorkflow did a bare oras manifest fetch — a transient read-after-write blip failed the whole publish with zero backoff, even though every phase before it was protected.
• Retry backoff wasn't interruptible. retry_on_transient slept via plain time.sleep. A Stage-1 job (running on a ParallelShellExecutor worker thread) blocked mid-backoff wouldn't notice Ctrl-C — the executor's interrupt handling returns immediately on the main thread, but ThreadPoolExecutor registers an atexit hook that joins every thread it ever spawned, so the process wouldn't actually exit until that sleep (and any remaining retry attempts) finished, up to ~62s per stuck job with default settings.

Changes

• retry_on_transient() gains an injectable sleep callable (defaults to time.sleep, looked up fresh per call so existing patch("posit_bakery.retry.time.sleep") tests keep working unmodified).
• CommandRunner.sleep() (new, in the parallel module): sleeps in short slices, checking the bound executor's shutdown flag between slices, raising a new ExecutorInterrupted as soon as shutdown is observed — so a mid-backoff job unwinds within about one slice interval of Ctrl-C instead of blocking process exit.
• OrasIndexCreateWorkflow and SociConvertWorkflow's pull-step retries (the only retries reachable from a Stage-1 ShellJob worker thread) now pass sleep=runner.sleep when a runner is available.
• OrasIndexVerifyWorkflow gains a retry_policy field and now retries transient errors on the final tag-resolution check, mirroring the existing Create/Copy pattern. No runner/interrupt plumbing there — it runs on the main thread, not inside the executor, so there's no process-exit-blocking risk to fix.

Explicitly out of scope (see design doc): unifying OrasWaitForSourcesWorkflow's poll loop onto RetryPolicy (different, already-correct mechanism), adding jitter, changing RetryPolicy defaults.

Verification

• just test — 1947 passed; ruff check + ruff format --check clean.
• Each commit individually reviewed (spec compliance + code quality) before merge into this branch; a final whole-branch review confirmed the cross-task composition (retry → CommandRunner.sleep → ExecutorInterrupted propagation through _run_job) is correct end to end and all stated non-goals were honored.
• Known follow-up (not blocking): OrasWaitForSourcesWorkflow's own poll sleep is the one Stage-1 wait left non-interruptible (~5s Ctrl-C latency bound vs. the ~62s this PR fixes for retry backoff) — same one-line fix pattern would close it if desired.

🤖 Generated with Claude Code

[github-actions]

Test Results

1 970 tests  +11   1 970 ✅ +11   8m 16s ⏱️ ±0s
    1 suites ± 0       0 💤 ± 0 
    1 files   ± 0       0 ❌ ± 0 

Results for commit 5672335. ± Comparison against base commit 69ee43c.

♻️ This comment has been updated with latest results.

[ianpittwood]

Tracked by #648.