chore: satisfy prettier in frontend and e2e

`checks.yml` runs `npm run format:check` for both projects and both were failing.

- frontend/src/lib/ui-store.ts is mine, unformatted since the round-1 upload-queue
  badge fix — the same miss as the rustfmt one: I gated on svelte-check and eslint
  but never on format:check.
- e2e/loadtest/* and e2e/shots.mjs have been unformatted since 7758270 and are
  unrelated to the audit work. Fixed here because they block the same gate and the
  fix is mechanical; no behaviour change in either project.

Still red and deliberately NOT fixed here: `npm run lint` in the frontend reports
`svelte/prefer-svelte-reactivity` on routes/diashow/+page.svelte:208 (a mutable
`Set` where the rule wants `SvelteSet`), pre-existing since 5009590. That one is a
real reactivity change in code I have no test coverage for, so it belongs in its
own change rather than smuggled into a formatting commit.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

e2e/loadtest/README.md

@@ -9,12 +9,12 @@ acting as the showcase display.
 
 **Validate the shipping config.** We run at the real production defaults —
 compression concurrency (`COMPRESSION_WORKER_CONCURRENCY`, default **2**), DB
-pool (default **10**), quotas **on** — and answer: *does the app survive the
-event, and how far behind real-time does the diashow fall?*
+pool (default **10**), quotas **on** — and answer: _does the app survive the
+event, and how far behind real-time does the diashow fall?_
 
 The headline metric is **pipeline latency**: time from an upload succeeding to
-its preview being ready (`upload-processed` SSE event) — i.e. *how long until the
-photo appears on the diashow*. A backlog that builds is fine; a backlog that
+its preview being ready (`upload-processed` SSE event) — i.e. _how long until the
+photo appears on the diashow_. A backlog that builds is fine; a backlog that
 **never drains** is a fail for a live event.
 
 ## Methodology: what we change vs. shipping
@@ -86,13 +86,13 @@ compression backlog to drain** before reporting.
 
 ## What the flags mean
 
-| Flag | Meaning |
-|------|---------|
-| `✗ 5xx` | server errored under load — hard fail |
-| `✗ 507` | quota rejected uploads — disk/quota misconfig for the event size |
+| Flag                      | Meaning                                                                      |
+| ------------------------- | ---------------------------------------------------------------------------- |
+| `✗ 5xx`                   | server errored under load — hard fail                                        |
+| `✗ 507`                   | quota rejected uploads — disk/quota misconfig for the event size             |
 | `✗ backlog did not drain` | compression can't keep up even after uploads stop — diashow never catches up |
-| `⚠ pipeline p95 > 60s` | photos take >1 min to appear on the diashow at peak |
-| `⚠ SSE resyncs` | live consumers lagged the broadcast channel |
+| `⚠ pipeline p95 > 60s`    | photos take >1 min to appear on the diashow at peak                          |
+| `⚠ SSE resyncs`           | live consumers lagged the broadcast channel                                  |
 
 ## Knobs
 
@@ -101,7 +101,7 @@ All via env (see header of `driver.mjs`): `LT_GUESTS`, `LT_IMAGES`,
 `LT_TRUNCATE`, `LT_DRAIN_TIMEOUT_SEC`, `LT_KEEP_RATELIMITS`, `LT_BASE`,
 `LT_APP_CONTAINER`, `LT_DB_CONTAINER`.
 
-To later answer *"what config should I deploy?"*, re-run with a rebuilt stack
+To later answer _"what config should I deploy?"_, re-run with a rebuilt stack
 that sets `COMPRESSION_WORKER_CONCURRENCY` higher (boot-time env var in
 `docker-compose.test.yml`) and compare the pipeline-latency / drain numbers.