test: replace coverage that could not fail with coverage that can

`backend/tests/` follows a house rule of copying production SQL character-for-
character rather than calling `src/`, because the crate is a binary and nothing
in it is importable from an integration test. For pinning behaviour that already
existed that is a defensible trade. Applied to a NEW fix whose only coverage is
the copy, it proves nothing: the fix and its test become two independent
implementations, and deleting the fix leaves the test green.

`audit_names.rs` did exactly that. It never called `audit::record` — it
reimplemented `resolve_names` and the INSERT inside the test file, down to a
hardcoded `.bind("host")`, and then asserted `actor_role == "host"` against its
own literal. That assertion could not fail for any change to the code it named,
and grep confirmed there was no other coverage of the audit-name work anywhere.

Moved into `#[cfg(test)]` inside `services/audit.rs`, where the real function IS
callable. CI already runs `cargo test --all-features` with a live DATABASE_URL,
so `#[sqlx::test]` works there; verified all four run and pass. The role
assertion now compares against `UserRole::as_str()` itself rather than a literal,
so it tracks a rename instead of pretending to, plus an explicit `assert_ne!`
against the Debug spelling.

Also:

- `retry-after-release.spec.ts` filtered the feed on `u.id === original.id` to
  prove "no second row was created". A duplicate gets a fresh uuid and could
  never match, so the filter yielded exactly 1 whether the gallery held one copy
  or five. Counts by uploader now, with the original's identity asserted
  separately. (The rest of that spec is sound — its 403 control and replay-id
  check both fail if the header fast-path is reverted.)

- `upload_after_release_commits_sees_the_lock_and_is_rejected` claimed the
  handler answers `UploadsLocked`. It answers `GalleryReleased` since the check
  order was inverted on this branch, and the test asserts no variant at all.
  Documented what it actually covers (the locked READ) and where the ordering IS
  covered (two e2e specs).

- Two `// SRC:` pointers had drifted ~130 lines into unrelated code, which is how
  a hand-copied fixture silently stops matching its original. Now named, not
  numbered.

- `emptyOutDir: false` claimed a failed viewer build "leaves the last good
  artifact in place". True for the `generateBundle` error, false for the newer
  `writeBundle` assertion, which fires after Vite has already written the file.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

frontend/export-viewer/vite.standalone.config.js

@@ -115,8 +115,17 @@ export default defineConfig({
 		// viewer at all. Before the guard existed the build could not fail, so neither could this.
 		//
 		// The only output is a single `index.html`, overwritten on every successful build, so
-		// there is nothing to accumulate — and a failed build now leaves the last good artifact in
-		// place instead of deleting it.
+		// there is nothing to accumulate.
+		//
+		// This protects ONE of the two failure paths, not both. `inlineThemeFonts` errors from
+		// `generateBundle`, before anything is written, so the previous artifact survives intact.
+		// The external-asset assertion errors from `writeBundle` — which runs AFTER Vite has
+		// written `index.html` — so that failure does overwrite the good viewer with the broken
+		// one. It cannot ship: the build exits non-zero, and `the_keepsake_viewer_is_compiled_into_
+		// this_binary` plus the `!html.contains("url(/")` assertion both fail the Rust test suite
+		// before any image is built. But if a `writeBundle` failure is what you are looking at,
+		// restore the artifact with `git checkout backend/static/export-viewer/` rather than
+		// assuming the working copy is still the last good one.
 		emptyOutDir: false,
 		target: 'es2020'
 	}