fix(e12): close what round one broke, and revert two fixes that overreached

Round two of the review loop, on round one's own diff. Two of its findings were
regressions the fixes themselves introduced, which is exactly what the loop is for:

**A per-user refusal was writing onto a shared row.** MediaAssets are deduped across
users, and the generic failure handler puts the message on the asset — right for an
upstream failure, wrong for "your storage is full". Two users queuing the same video share
one asset, so the first user hitting their cap failed the second user's job with the first
one's private reason, telling someone with an empty library to free up space. The refusal
now raises `_OwnerRefused`, caught separately: the job fails, the asset goes back to
`pending` for whoever else holds it. Pinned by a test that drives `_download` directly —
the refusal happens before extraction, so nothing needs stubbing.

**The restore scripts restarted the app, undoing the restore.** `docker compose start`
re-runs the container command, and that runs `alembic upgrade head` — so on the rollback
path this documents as recommended (restore the dump, THEN pin the older tag) the newer
image immediately re-applied the migrations the restore had just undone, and on a FAILED
restore it put the app back on a half-restored schema. Both are the opposite of why the
stop was added. Nothing is restarted automatically now; the scripts say what to run and
when, and the docs' snippets say the same.

**Reverted rather than patched:** the OnboardingWizard toast (the wizard already renders
that failure inline, next to a Retry button — three recoveries for one failure), and
`useVerifyEntry`'s "each new link clears the other". The latter blanked the signed-out
card's only banner, where nothing renders the reset flag to replace it. The two states are
independent again; what changes is that `dismiss` peels ONE layer, which is what the
original finding was actually about.

Also: `Stats` uses the YouTube helper rather than the bare one, so the route's English 403
detail no longer beats the translated fallback under a Hungarian UI; `urlparse` guarded
alongside `.port` (an unclosed bracket raised just as late), the reason renamed `malformed`
since "bad port" misdescribes it; three docstrings narrowed to what the code actually does
(the worker's byte check is per-job, not an aggregate ledger, and not on the edit path;
the redirect residual leaks a reachability oracle, which the note had denied; the
invalidation helper does not cover suspend); the pasted Windows recipe wrapped so `throw`
can stop it; the bash one-liner's failure branch no longer exits 0; and the tests that were
missing for the round-one fixes — the account panel's error paths, the invalidation set,
and the shared-asset case above.

Gate green: vitest 685, pytest 950.

frontend/src/lib/adminUsers.test.ts

@@ -0,0 +1,55 @@
+// @vitest-environment jsdom
+//
+// jsdom because the shared module reaches lib/api, which pulls in i18n's localStorage probe.
+import { describe, it, expect, vi } from "vitest";
+import { QueryClient } from "@tanstack/react-query";
+import { invalidateUserAccess, isEmailOff } from "./adminUsers";
+import { HttpError } from "./api";
+import { qk } from "./queryKeys";
+
+// The set matters, not the call: letting someone in changes three things a user can see at once —
+// the row, the pending queue, and the /api/me badge — and the account panel shipped invalidating
+// only the first two, so the badge went on claiming the person was stuck until a reload. Pinning the
+// keys here is what stops the two call sites drifting apart again, since neither component test
+// asserts on invalidation.
+describe("invalidateUserAccess", () => {
+  it("refreshes the row, the pending queue and the badge", () => {
+    const qc = new QueryClient();
+    const spy = vi.spyOn(qc, "invalidateQueries").mockImplementation(() => Promise.resolve());
+
+    invalidateUserAccess(qc);
+
+    const keys = spy.mock.calls.map(([a]) => JSON.stringify(a?.queryKey));
+    expect(keys).toEqual(
+      [qk.adminUsers(), qk.adminPendingAccess(), qk.me()].map((k) => JSON.stringify(k)),
+    );
+  });
+
+  it("also refreshes one account's gate readout when given an id", () => {
+    const qc = new QueryClient();
+    const spy = vi.spyOn(qc, "invalidateQueries").mockImplementation(() => Promise.resolve());
+
+    invalidateUserAccess(qc, 7);
+
+    expect(spy.mock.calls.map(([a]) => JSON.stringify(a?.queryKey))).toContain(
+      JSON.stringify(qk.adminUserAccess(7)),
+    );
+  });
+});
+
+// The admin-side resend deliberately reports failures (the public one is silent), so it has to be
+// able to say WHICH — a no-SMTP instance is a configuration answer, not a bug.
+describe("isEmailOff", () => {
+  it("recognises the no-mail refusal", () => {
+    expect(isEmailOff(new HttpError(409, "x", { code: "resend", reason: "email_off" }))).toBe(true);
+  });
+
+  it("is false for any other failure, including a non-HttpError", () => {
+    expect(isEmailOff(new HttpError(422, "x", { code: "resend", reason: "send_failed" }))).toBe(
+      false,
+    );
+    expect(isEmailOff(new HttpError(500, "x", null))).toBe(false);
+    expect(isEmailOff(new TypeError("Failed to fetch"))).toBe(false);
+    expect(isEmailOff(undefined)).toBe(false);
+  });
+});

frontend/src/lib/adminUsers.ts

@@ -9,7 +9,11 @@ import { qk } from "./queryKeys";
 // Grouped invalidation lives per domain rather than in `qk` (see the contract note there);
 // `invalidateDownloads` is the same pattern for the downloads domain.
 
-/** Everything that goes stale when a user's ACCESS state changes (activate, approve, suspend).
+/** Everything that goes stale when an account is LET IN (activate, approve an invite).
+ *
+ * Suspend and delete move the same counters and are deliberately NOT wired here yet — they have
+ * their own pre-existing staleness, tracked separately, and widening this in passing would put an
+ * unreviewed change in a review-fix diff.
  *
  * `me` is in the set because the admin badge counts pending activations, and `admin-pending-access`
  * because the queue is exactly the list of accounts this action removes one from — refreshing only

frontend/src/lib/useVerifyEntry.ts

@@ -59,15 +59,7 @@ export function useVerifyEntry(): VerifyEntry {
       // Both halves of the mailed pair arrive the same way — pasted into a running tab, which is a
       // same-document navigation the import-time snapshot never sees. The verify half got this
       // listener in E9.5 S2; the reset half was left out, so it stayed silent (DX-17).
-      if (hash.get("reset")) {
-        setResetPending(true);
-        // Same rule as a second verify link below: a newly pasted link must not be shadowed by a
-        // banner still standing from the previous one. Without this the reset guidance is
-        // unreachable whenever an unread verify outcome is on screen, and `dismiss` then clears the
-        // pending flag along with the outcome — the DX-17 silence, one state later.
-        setOutcome(null);
-        setEmail(null);
-      }
+      if (hash.get("reset")) setResetPending(true);
     };
     // replaceState (how clearEntryUrl strips the fragment) does NOT fire hashchange, so this cannot
     // feed itself.
@@ -82,12 +74,9 @@ export function useVerifyEntry(): VerifyEntry {
     clearEntryUrl();
     if (!token || consumed.current.has(token)) return;
     consumed.current.add(token);
-    // A second link arriving over an unread first outcome must not leave the OLD banner standing —
-    // whichever kind that outcome was. Clearing both keeps the two states mutually exclusive, which
-    // is what lets the single `dismiss` below clear "whatever is showing" without eating the other.
+    // A second link arriving over an unread first outcome must not leave the OLD banner standing.
     setOutcome(null);
     setEmail(null);
-    setResetPending(false);
     api
       .verifyEmail(token)
       .then((r) => {
@@ -112,9 +101,18 @@ export function useVerifyEntry(): VerifyEntry {
     outcome,
     email,
     resetPending,
+    // Dismiss peels ONE layer. The two states are independent — a reset link can arrive over an
+    // unread confirmation, and a slow /auth/verify can resolve after one did — so clearing both at
+    // once silently discards whichever the user had not read yet. The banner shows the reset
+    // guidance first (it is the one with something to do), and dismissing it reveals the outcome
+    // underneath rather than taking it with it.
     dismiss: () => {
+      if (resetPending) {
+        setResetPending(false);
+        return;
+      }
       setOutcome(null);
-      setResetPending(false);
+      setEmail(null);
     },
   };
 }

frontend/src/lib/verifyEntry.dom.test.tsx

@@ -34,6 +34,7 @@ async function mountAt(url: string, verifyEmail: ReturnType<typeof vi.fn>) {
       <>
         <div data-testid="outcome">{`${entry.outcome ?? "none"}:${entry.email ?? "-"}`}</div>
         <div data-testid="reset">{entry.resetPending ? "reset-pending" : "-"}</div>
+        <button data-testid="dismiss" onClick={entry.dismiss} />
       </>
     );
   }
@@ -157,11 +158,10 @@ describe("confirming an emailed verification link", () => {
     expect(screen.getByTestId("reset").textContent).toBe("reset-pending");
   });
 
-  // The two banners are mutually exclusive by construction, and each new link clears the other. Once
-  // they could coexist, the reset guidance was gated behind "no outcome showing" and a standing
-  // confirmation swallowed it — DX-17 again, one state later — and dismissing that confirmation then
-  // cleared the pending reset with it, so the guidance could never appear at all.
-  it("lets a pasted reset link supersede a confirmation banner still on screen", async () => {
+  // A reset link can arrive over an unread confirmation (and a slow /auth/verify can resolve after
+  // one did), so both states can be set at once. Neither may eat the other: `dismiss` used to clear
+  // both, which is how the reset guidance could be destroyed before it was ever rendered.
+  it("keeps a pasted reset link and an unread confirmation, and dismisses them one at a time", async () => {
     const verifyEmail = vi.fn().mockResolvedValue({ ok: true, email: "someone@example.com" });
 
     const outcome = await mountAt("/#verify=tok-first", verifyEmail);
@@ -172,25 +172,18 @@ describe("confirming an emailed verification link", () => {
       window.dispatchEvent(new HashChangeEvent("hashchange"));
     });
 
+    // Both live: the reset is pending AND the confirmation is still unread.
     expect(screen.getByTestId("reset").textContent).toBe("reset-pending");
-    expect(outcome()).toBe("none:-"); // the old banner is gone, so nothing shadows the guidance
-  });
+    expect(outcome()).toBe("ok:someone@example.com");
 
-  it("lets a pasted verify link supersede a pending reset notice", async () => {
-    // The other direction, for the same reason: whichever link arrived last is the one the user is
-    // acting on, and only one of the two states may be true for `dismiss` to be unambiguous.
-    const verifyEmail = vi.fn().mockResolvedValue({ ok: true, email: "second@example.com" });
-
-    const outcome = await mountAt("/#reset=first", verifyEmail);
-    expect(screen.getByTestId("reset").textContent).toBe("reset-pending");
-
-    await act(async () => {
-      window.history.replaceState(window.history.state, "", "/#verify=tok-second");
-      window.dispatchEvent(new HashChangeEvent("hashchange"));
-    });
-
-    expect(outcome()).toBe("ok:second@example.com");
+    // One dismiss peels the reset guidance and leaves the confirmation standing…
+    await act(async () => screen.getByTestId("dismiss").click());
     expect(screen.getByTestId("reset").textContent).toBe("-");
+    expect(outcome()).toBe("ok:someone@example.com");
+
+    // …and the next one clears that.
+    await act(async () => screen.getByTestId("dismiss").click());
+    expect(outcome()).toBe("none:-");
   });
 
   // This hook runs on the FIRST commit of App, which is several commits before the setup wizard, the