fix(publisher): retry one exact failed lift job

[branarakic]

Impact

The async publisher admin boundary can now retry exactly one failed lift job by jobId. This lets the Blackbox harness recover a retryable VM publication without sweeping unrelated historical failures or submitting a second publish request.

Before

sequenceDiagram
    participant Harness
    participant Job as Failed VM job
    participant Publisher
    Harness->>Job: Poll status
    Job-->>Harness: failed and retryable
    Harness->>Harness: Keep polling until timeout
    Note over Publisher: Bulk retry selects every failed job

Loading

After

sequenceDiagram
    participant Harness
    participant API as Publisher API
    participant Job as Exact VM job
    Harness->>Job: Poll status
    Job-->>Harness: failed and retryable
    Harness->>API: Retry failed jobId only
    API->>Job: Reset exact job to accepted
    Job-->>Harness: finalized

Loading

Validation

• Publisher queue E2E: 14 passed
• CLI publisher boundary: 18 passed
• Publisher dependency build: passed
• CLI dependency build: passed
• Diff check: passed

Live trigger

The Testnet 500/500 diagnostic run exposed a retryable VM job in failed state. The harness recognized it as retryable but had no safe exact-job retry endpoint, so it polled until timeout. The only existing API retried all failed jobs; this PR closes that safety gap.

[branarakic]

Review fixes are now in 4c93034. Exact and bulk retry are separate first-class operations; empty exact job IDs fail before HTTP; exact ApiClient serialization is covered. Validation: publisher recovery 14/14, CLI and API boundary 104/104, publisher build pass, CLI build pass, diff check pass.