Serve the userscript from the backend; card + loading fixes (#8)

Serves the userscript from the backend so Violentmonkey auto-updates it, plus two panel fixes.

## Backend: `GET /u/{token}/manga-bookmark.user.js`

The script is read off disk per request from `USERSCRIPT_PATH` and streamed back with its `@version` line rewritten.

- **Token in the path, not a header.** Violentmonkey's update poll sends no `Authorization` header, and the script embeds `API_TOKEN` in plain text — an open URL would hand that token to anyone who guessed it. Compare is constant-time.
- **404, never 401**, for both a wrong token and a missing file: a prober learns nothing about whether the route exists.
- Registered outside `withAuth` and outside the `WEB_PASSWORD` gate, so the script is installable on a deployment that never enabled the web UI.
- Stdlib only (`crypto/subtle`, `os`, `regexp`) — no new Go dependencies.

**The served `@version` is derived from the file's mtime** (`YYYY.MM.DD.HHMM`, UTC), discarding whatever the file body says. Violentmonkey only updates when the served version sorts higher than the installed one, so a body-derived version means one typo or accidental downgrade freezes updates forever. An mtime-derived version is monotonic by construction. A file with no `@version` line is served byte-identical. `os.Stat` runs before `os.ReadFile`, so a concurrent edit can only serve new content under an old stamp — which self-heals on the next poll — never the reverse.

## Bindmount

`./userscript` is bindmounted read-only at `/userscript`. The script is deliberately **not** copied into the image: the build context stays `./backend`, and widening it would churn every `COPY` path for a file the mount always supplies. Editing the file on the VPS is live on the next poll — no rebuild, no restart. `git pull` restores the committed version, so a redeploy always ships the repo's script; checkout sets mtime to now, so even a rollback serves a *higher* version and is adopted. Without the mount the endpoint 404s and logs it; bookmark sync is unaffected.

`@downloadURL` / `@updateURL` are literal URLs in the metadata block — it is parsed before any JS runs, so `API_BASE`/`API_TOKEN` cannot be interpolated. The token was already committed in this file, so this adds no new exposure.

## Userscript UI

- **Card actions moved under the subtitle.** Only the cover and the title continue reading now; the subtitle and the action row are inert siblings in the text column. A thumb that misses ★ lands on nothing, and Remove is never inside a link.
- **Loading spinner** while the first fetch is in flight — the panel used to read as frozen on the first open after a cold start. It draws only when there is nothing cached to draw instead, so a populated list never flaps.

## Verification

- `go test -count=1 ./...` — ok, 7.070s
- `node --check` clean; `node --test userscript/test/logic.test.js` — 14/14
- Live `docker compose` smoke: `/healthz` 200, wrong token 404, script served with a stamped `@version 2026.07.28.1057` and both metadata URLs present; `touch`ing the file advanced the served version to `2026.07.28.1100` with no restart.

Layout and spinner are verified on-device — there is deliberately no DOM test harness.

Reviewed-on: #8
Co-authored-by: Sulthan Zaki <sultankiki05@gmail.com>
Co-committed-by: Sulthan Zaki <sultankiki05@gmail.com>

DEPLOY.md

@@ -166,6 +166,12 @@ const API_TOKEN = "<same token as .env>";
 The token sits in the userscript's isolated world — the manga sites' JS can't
 read it.
 
+Also edit the `@downloadURL`/`@updateURL` metadata lines near the top of the
+file — they ship hardcoded to this deployment's domain and token, so a
+deployer who skips them ends up auto-updating from someone else's backend.
+See "Installing / updating the userscript" below for how those two lines are
+used.
+
 ---
 
 ## 5. Install on Bromite
@@ -218,3 +224,43 @@ SQLite data persists in the named volume `bookmarks-data` across rebuilds.
 | `compose ... config` errors about `API_TOKEN` | Run compose from the dir with `.env`, or export the vars. |
 
 Backend config reference and endpoint list: see `README.md`.
+
+---
+
+## Installing / updating the userscript
+
+The backend serves the script itself, so Violentmonkey can auto-update it.
+Complements §4 above — that step points `API_BASE`/`API_TOKEN` at your
+backend; this one points `@downloadURL`/`@updateURL` at the same place so
+auto-updates come from it too.
+
+Install once, on the phone (Cromite + Violentmonkey):
+
+```
+https://manga-api.<your-domain>/u/<API_TOKEN>/manga-bookmark.user.js
+```
+
+Open that URL in Cromite; Violentmonkey offers to install it. The token is in
+the path because Violentmonkey's update poll sends no `Authorization` header,
+and the script embeds `API_TOKEN` in plain text — an open URL would leak it. A
+wrong token answers 404.
+
+Updating, without a redeploy:
+
+```bash
+vi userscript/manga-bookmark.user.js   # on the VPS, in this checkout
+```
+
+`./userscript` is bindmounted read-only into the container and read fresh on
+every request, so the edit is live immediately. The served `@version` is derived
+from the file's mtime (`YYYY.MM.DD.HHMM`, UTC), not from the `@version` in the
+file, so any edit outranks the installed copy and Violentmonkey pulls it on its
+next check. The `@version` in the repo is a human marker only.
+
+Updating via redeploy: `git pull` overwrites the file with the committed
+version, which is the intended behaviour — a deploy always ships the repo's
+script. Note that `git pull` sets mtime to checkout time, so even a rollback
+serves a *higher* version and is adopted.
+
+If the mount is missing, the endpoint answers 404 and logs it; bookmark sync is
+unaffected.