fix(uploads): make the drift guards fail for the reasons they claim

Deep-review round 3, targeted at the surfaces round 2's fix commit changed.
Five of the eight findings are the same shape: the guards written to stop
half-done sweeps were themselves half-done.

test_upload.py's display-field guard walked only `ast.Assign`, so the one
writer with an unbounded REQUEST HEADER behind it — `spool_upload`'s
`display_name=display_text(...)` keyword — was invisible to the guard meant
to protect it. It also stopped at `app/routes/`, missing the four writers in
`downloads/` that actually construct the row, and asserted `not offenders`,
which enforces nothing once a refactor moves the writers out of its view.
It now walks assignments AND keywords across `app/`, and holds exact set
equality against a registry of all twelve write sites with each one's value.

test_body_limit.py's release guard used `any(... ast.walk(fn))`, which
accepts a `release_read_connection` that runs AFTER the await it exists to
precede — satisfying the letter of the rule while pinning a connection for
exactly the transfer it was supposed to free. Position is checked now, and a
late release is its own, louder failure. The registry keyed sites by file
basename while scanning recursively, and `admin.py`, `discover.py` and
`playlists.py` each exist both at the top level and under `plex/` — the same
entry-collapse the registry was widened to close. Keyed by relative path now.
And all three guards recognised a body read only by the `capped_` naming
convention, so a route spelling `await request.body()` inline declared no
ceiling, released no connection, and was invisible to every one of them.

`release_read_connection`'s precondition claimed the caller "must have
NOTHING PENDING, and that is checked rather than described" while checking
only UNFLUSHED ORM work. Measured: after `add`+`flush` all three collections
are empty and the rollback loses the row, and Core DML never enters them at
all — both of them this codebase's canonical write shapes. It now also asks
the transaction directly via `pg_current_xact_id_if_assigned()`.

`errors.tooLarge` was reworded to "try a smaller file", but that key answers
every route's body cap: the issue composer's over-size JSON draft got advice
about a file it does not have. Back to payload-neutral; the file-specific
sentence keeps its own key.

The upload dialog's new danger border outranked `dragOver`, so a user
replacing an over-cap file got no sign the drop zone was live — and with a
file picked the label shows its name rather than "drop it here", so the
border was the only feedback left.

Four further findings were refuted 3/3 and are not fixed: `aria-invalid` on
the drop zone (measured in Chromium — the AX node does carry it on a native
button), a bidi-override spoof through `display_text` (the served filename
already strips those categories, and the proposed filter would have broken
every ZWJ emoji), and `capped_body` not draining (the screenshot route's edge
ceiling equals its own cap, so that refusal is unreachable, and the log sink
is sent by beacon with nobody reading the answer).

frontend/src/components/UploadDialog.dom.test.tsx

@@ -114,6 +114,24 @@ describe("UploadDialog", () => {
     expect(zone.getAttribute("aria-describedby")).toBe(screen.getByRole("alert").id);
   });
 
+  it("still highlights as a drop target while the picked file is over the cap", async () => {
+    // The state a user is in when they see the refusal is "replace this file". With a file
+    // already picked the zone's label shows its NAME rather than `dropActive`, so the border is
+    // the only feedback that a drag is over a live target — and a danger border that outranks the
+    // drag state reads as "drag-and-drop is off now", sending the user hunting for a control that
+    // does not exist. The drop would have worked.
+    h.downloadUsage.mockResolvedValue({ upload_max_bytes: CAP });
+    wrap();
+    await waitFor(() => expect(h.downloadUsage).toHaveBeenCalled());
+    pickFile(CAP + 1, "big.bin");
+    const zone = screen.getByText("big.bin").closest("button")!;
+    expect(zone.className).toContain("border-danger");
+
+    fireEvent.dragEnter(zone);
+    expect(zone.className).toContain("border-accent");
+    expect(zone.className).not.toContain("border-danger");
+  });
+
   it("swallows a Submit press that arrives while the button still holds focus", async () => {
     // The OTHER half of "never sent": the test above covers the natively disabled button (not
     // focused), this one covers the soft-disabled one. `ui/Button` is focus-safe, so a button that

frontend/src/components/UploadDialog.tsx

@@ -125,14 +125,22 @@ export default function UploadDialog({ onClose }: { onClose: () => void }) {
         disabled={busy}
         // The refusal is tied to the control it invalidates, not left to a one-shot announcement:
         // the drop zone reads as invalid and points at the sentence, so a reader who tabs back to
-        // it hears WHY, and the border says the same thing without colour being the only signal.
+        // it hears WHY. (Measured, because `aria-invalid` is not in `button`'s ARIA-supported
+        // list: Chromium's accessibility node for a native button does carry `invalid` from this
+        // attribute.) The signal that is NOT colour is the sentence below, visible to everyone —
+        // the border only reinforces it.
         aria-invalid={tooBig}
         aria-describedby={tooBig ? refusalId : undefined}
+        // `dragOver` outranks `tooBig`: a drag is transient and the refusal repaints the instant
+        // the drop lands, whereas a zone that stays red under the pointer tells the user their
+        // drop target is dead — in the one state where they are trying to replace the file. With
+        // a file picked, the label below shows its name rather than `dropActive`, so this border
+        // is the ONLY feedback that the zone will accept the drop.
         className={`w-full flex flex-col items-center justify-center gap-2 rounded-xl border-2 border-dashed px-4 py-8 text-center transition disabled:opacity-60 ${
-          tooBig
-            ? "border-danger"
-            : dragOver
-              ? "border-accent bg-accent/5"
+          dragOver
+            ? "border-accent bg-accent/5"
+            : tooBig
+              ? "border-danger"
               : "border-border hover:border-fg/40"
         }`}
       >

frontend/src/i18n/locales/en/errors.json

@@ -3,7 +3,7 @@
   "generic": "The server couldn't carry out that action. Please try again.",
   "demo": "This isn't available in the demo account.",
   "validation": "Some of the values you entered weren't valid. Please check them and try again.",
-  "tooLarge": "That was too large to send. Try a smaller file.",
+  "tooLarge": "That was too large for the server to accept.",
   "server": "Server error",
   "syncCooldown": "You've synced a few times just now — give it a few minutes. The YouTube budget is shared with everyone on this instance, and background syncing keeps running either way.",
   "notFound": {

frontend/src/i18n/locales/hu/errors.json

@@ -3,7 +3,7 @@
   "generic": "A szerver nem tudta végrehajtani a műveletet. Próbáld újra.",
   "demo": "Ez a bemutató fiókban nem érhető el.",
   "validation": "Néhány megadott érték érvénytelen volt. Ellenőrizd, majd próbáld újra.",
-  "tooLarge": "Ez túl nagy volt a küldéshez. Próbáld kisebb fájllal.",
+  "tooLarge": "Ez túl nagy, a szerver nem fogadta el.",
   "server": "Szerverhiba",
   "syncCooldown": "Az imént többször is szinkronizáltál — várj pár percet. A YouTube-keret közös az instance összes felhasználójával, a háttérszinkron pedig így is fut tovább.",
   "notFound": {

frontend/src/lib/api/core.ts

@@ -131,6 +131,11 @@ function localizeDetail(d: unknown): string {
   // 200 MiB over loopback, and measured as a bare `onerror` through a dev proxy. That is why the
   // upload dialog checks the file against `upload_max_bytes` BEFORE sending — this branch is what
   // happens when that check could not run.
+  //
+  // `errors.tooLarge` stays PAYLOAD-NEUTRAL for that reason. It is also what a JSON form gets
+  // (`debug_sessions` refuses an over-size draft with the same bare code), so wording it as advice
+  // about a file told the issue composer's user to pick a smaller one — of nothing. The
+  // file-specific sentence is `downloads.errors.upload.tooLarge`, one branch up, which has a number.
   if (o?.code === "too_large") return t("errors.tooLarge");
   // SEC-12: a download URL the server refuses to fetch. The reasons are deliberately distinct —
   // "we could not look that host up" is a different thing to tell someone than "we will not fetch