docs: production proxy path + capability-URL guidance

Two small documentation gaps the second-pass audit flagged:

- CLAUDE.md described only the Vite dev proxy ("Vite dev-proxies to
  the backend"), which left the production path opaque. Now lists
  both: the Vite proxy for `npm run dev` and
  `frontend/src/hooks.server.ts` for adapter-node. Same-origin cookie
  story called out explicitly.

- `/api/v1/files/{key}` is an unauthenticated capability URL by
  design — reads stay public, keys are unguessable v4 UUIDs, leaked
  URL leaks one file. Documented both in `backend/src/api/files.rs`'s
  module doc (with a pointer at the seam a future
  feat/private-libraries branch would use) and in a new "Capability
  URLs" section in README so a casual reader doesn't mistake the lack
  of auth for an oversight.

No code or behaviour change.

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

backend/src/api/files.rs

@@ -4,6 +4,17 @@
 //!
 //! The handler uses `Storage::get_stream` so a multi-MB page is piped to
 //! the client a chunk at a time instead of buffered server-side.
+//!
+//! **Auth model — capability URLs by design.** This endpoint is
+//! deliberately unauthenticated: reads stay public per the project
+//! brief, and per-page authorisation would require either a per-request
+//! ownership lookup (covers + pages are scoped by manga, not user) or a
+//! signed-URL scheme. Mangalord instead relies on the keys being
+//! unguessable — `mangas/{uuid}/...` and
+//! `mangas/{uuid}/chapters/{uuid}/...` — so a leaked URL leaks at most
+//! the one referenced file. A future feat/private-libraries branch
+//! would gate this endpoint behind a `Storage::owner_of(key)` check;
+//! the seam is intentional.
 
 use axum::body::Body;
 use axum::extract::{Path, State};