fix(security): bound password input before zxcvbn, and drop the legacy media mounts

Two findings from the GHSA-pwx6-5pqc-c5xq scan bundle, both verified against
the code and reproduced before fixing.

**Unauthenticated denial of service via password strength (csf_495d53fa).**
POST /api/auth/password-strength takes `body('password').notEmpty()` with no
upper bound, sits behind express.json({ limit: '50mb' }), and hands the string
to zxcvbn, whose matching is superlinear and runs synchronously on the event
loop. Measured on this codebase, in ms of blocked loop: 128 -> 41, 512 -> 1367,
1000 -> 5097, 5000 -> did not return in two minutes. One unauthenticated
request of about a kilobyte stops the whole process for five seconds; a few
kilobytes stops it indefinitely. The /api/auth rate limit does not help when a
single request is already enough.

The cap lives in validatePassword() so it covers every caller, present and
future; the route validator is defence in depth. 128 keeps the worst case at
the cost of an ordinary request while staying far above any real password --
bcrypt consumes only the first 72 bytes, so length past that adds no entropy to
the stored hash anyway. This is the only unauthenticated reach into zxcvbn:
setup is token-gated and self-closing, and acceptInvite/adminAuth use the
regex-only validator in passwordGenerator.

**The /photos and /thumbnails static mounts (csf_9aa6afe6, csf_559cd5cc,
csf_b14d462e, csf_547d26fa, and the gallery half of csf_34e420af).**
They served the raw originals and thumbnail trees behind photoAuth, which
authorises on a slug match. A static file server cannot apply per-photo rules,
so everything the gallery API decides was absent: allow_downloads, per-category
allow_downloads, watermarking, the resolution cap, reveal-mode windows,
visibility='hidden', download logging, and the customer-assignment re-check
that makes revocation immediate. photoAuth also bcrypt-compares an
x-gallery-password header per request with no limiter -- both rate-limit gates
return early for non-/api paths -- so the mount was an unmetered password
oracle. The filenames needed to drive all of this are handed to every guest in
the photos listing.

Nothing builds these URLs: no reference in frontend/src, none in the email
templates, and the only backend mentions are the /api/admin/photos/... API
routes and a maintenance-mode prefix list. The equivalent authorised routes are
/api/gallery/:slug/photo/:id and /thumbnail/:id. nginx still proxies the two
locations; they now 404, which is the intent.

**The /uploads mount (csf_1fc92f57).** It exposed the whole uploads/ root with
no auth middleware at all, and that root also holds signed contract PDFs
(uploads/contracts/signed) and client transfer files (uploads/transfers/<id>),
reachable by anyone who learned or guessed a filename. Narrowed to the two
public asset trees it exists for; contracts and transfers keep their own
authorised routes.

Removing the mounts leaves src/middleware/photoAuth.js unreferenced by
application code. Left in place deliberately -- deleting it and its tests is a
separate cleanup, and a smaller diff backports more safely.

Backend suite: 2742 passed.

backend/src/utils/passwordValidation.js

@@ -7,6 +7,21 @@ const zxcvbn = require('zxcvbn');
 const logger = require('./logger');
 
 // Configuration
+// zxcvbn's matching is superlinear in the input length and runs synchronously
+// on the event loop, so an unbounded password is a denial-of-service primitive
+// rather than a slow request. The reachable caller is
+// POST /api/auth/password-strength, which is unauthenticated and sits behind
+// express.json({ limit: '50mb' }) -- one request stops the whole process.
+//
+// Measured on this codebase (ms of blocked event loop per call):
+//   64 -> 12    128 -> 41    192 -> 105    256 -> 218
+//   384 -> 632  512 -> 1367  1000 -> 5097  5000 -> did not return in 2 min
+//
+// 128 keeps the worst case at the cost of an ordinary request while staying
+// far above any real password: bcrypt consumes only the first 72 bytes, so
+// anything longer already adds no entropy to the stored hash.
+const MAX_PASSWORD_LENGTH = 128;
+
 const PASSWORD_CONFIG = {
   minLength: 8, // Reduced from 12 to 8 for better usability
   requireUppercase: true,
@@ -34,6 +49,18 @@ const COMMON_PASSWORDS = [
 function validatePassword(password, options = {}) {
   const config = { ...PASSWORD_CONFIG, ...options };
   const errors = [];
+
+  // Bail before any superlinear work touches the string. This is the guard for
+  // every caller, including ones added later -- the per-route length validator
+  // is defence in depth, not the control.
+  if (typeof password === 'string' && password.length > MAX_PASSWORD_LENGTH) {
+    return {
+      valid: false,
+      errors: [`Password must be at most ${MAX_PASSWORD_LENGTH} characters`],
+      score: 0,
+      feedback: {},
+    };
+  }
   
   // Check if password exists
   if (!password || typeof password !== 'string') {
@@ -366,6 +393,7 @@ function logPasswordValidationFailure(context, errors, metadata = {}) {
 }
 
 module.exports = {
+  MAX_PASSWORD_LENGTH,
   validatePassword,
   validatePasswordInContext,
   generateSecurePassword,