feat(issues): Processing Issues page retry UI with a sequential client queue

Per issue card: a Retry button — error-severity issues previously had no
action at all (only warning/info got Dismiss). Right of the Errors stat
card: Retry all, which builds a queue of every issue currently on the
page and runs them strictly one at a time through the per-issue retry
endpoint. The browser is the queue — resource use is bounded to a single
book in flight, and no batch endpoint exists to maintain.

While the queue runs, the button shows an n/m counter and cards tint via
client-local state classes (the sanctioned island shape; the cards
themselves stay templ-rendered). After the queue drains, the page swaps
in the new /admin/libraries/:id/issues/content templ partial — the
unlinked-books htmx.ajax pattern with a reload fallback — so resolved
issues drop off server-side while failures remain listed, with a
summary toast and per-item error toasts carrying the real failure
reasons.

CSP discipline holds throughout: Alpine @click component methods, no
inline handlers, no js:-prefixed hx-vals.

web/static/input.css

@@ -2113,3 +2113,17 @@
 .nav-group-items[data-collapsed="true"] {
   display: none;
 }
+
+/* Processing Issues retry queue (2026-10): client-side per-card tints.
+   Cards themselves are templ-rendered; these only mark queue progress —
+   the post-queue partial swap restores server truth. */
+.issue-retrying {
+  opacity: 0.55;
+}
+.issue-retry-done {
+  border-color: var(--status-success) !important;
+}
+.issue-retry-failed {
+  border-color: var(--status-danger) !important;
+}
+