[plainprogrammer]

The art index panel on /admin/catalog now tells a hung build from an interrupted one, and says why and until when a build waits to retry.

Closes #79
Closes #80

What changed

• A hung art build reads "Interrupted" with a disabled button #79, a hung build. A running build whose heartbeat is over 10 minutes old while a worker still holds its job is stalled (MTG::ArtBuild#stalled?), not interrupted. The panel says it is building with no heartbeat for N minutes and what a restart does, instead of "Build it again" beside a disabled button. The button stays disabled, the page keeps polling and there is no failed-job link, as for a stalled refresh. A stale build whose job has failed or gone still reads "Interrupted", as PR fix(admin): show a crashed art build as interrupted at once #75 made it. catalog:status says the same.
• Art index panel hides the reason and time while its retry waits #80, a waiting retry. When the latest build failed and its own job is scheduled to run again, the panel reads "Queued to retry. The last build failed: …" with a "Retrying at" fact for that job. A build queued fresh still reads "Queued."
• One core change. Catalog::Operation::Queue#retry_at takes an optional job id, so a failure is given as the reason only for that build's own retry. It names no collectible; the refresh's use is unchanged.
• No view, CSS or helper change: the panel renders what the operation returns.
• Spec 015 (1.3.0: AC-4.11, AC-4.12, glossary, Error Scenarios), spec 011 (1.2.1), CLAUDE.md and docs/design-system/components/AdminCatalog.md match.

Decisions for you

1. The stalled wording gives advice ("restart the app") where the refresh's stalled line gives none. Issue A hung art build reads "Interrupted" with a disabled button #79 asked that it say what the admin can do. It says both outcomes of a restart: the build carries on, or reads interrupted and can be built again.
2. The retry reason is tied to the build's own job id, which is stricter than the refresh's rule (any failed run plus any scheduled job). The refresh was left alone.

Verification

• bin/ci: passed on the final commit (the pre-push run).
• New examples at model, operation, request and rake level, each seen failing first.
• One independent read-only review (Opus): no must-fix. It ran Solid Queue 1.7.0 in fork mode with a job hung in sleep: on a graceful stop the job went back to ready in 5 of 5 runs, so the re-run carries on. Its follow-ups (the wording after a hard kill, the retry time taken from the build's own job, one more case, two comments) are the last five commits.
• Not verified: a thread stuck in a C call, a real hung build on a live instance, and the panel in a browser (no markup changed; only the summary text and facts).

Known limits and follow-ups

• After a hard kill the job stays claimed until its process is pruned (5 to 10 minutes), so the panel reads stalled for that long before it reads interrupted.
• A build job that starts while a hung worker still holds the first closes the stalled build and runs beside it. Unchanged from main, and pinned by an existing spec.
• The reason shown is the stored message, exception class included: Admin catalog shows raw exception classes when a refresh or build fails #84.
• Once the scheduled retry is dispatched, or an admin retries the failed job from /admin/jobs, the panel reads plain "Queued." This matches the refresh.
• catalog:status still prints the failed build while its retry waits; the class comment says where the page and the status line differ.
• Spec 011's version row will conflict with the fix for Scryfall client retries inside the 30 seconds a 429 limits access for #81 when that lands; whichever merges second needs a small merge.
• docs/roadmap.md still lists A hung art build reads "Interrupted" with a disabled button #79 and Art index panel hides the reason and time while its retry waits #80 as open.

🤖 Generated with Claude Code