Security fixes: SSRF, staff role escalation, SPA-only gating, throttling, encrypted keys

Findings from the audit (50-check harness across guest/user/uploader/staff/
admin) and their fixes:

- SSRF: 'Download to Library' and the staged-upload resolve path fetched
  any http(s) URL. services.validate_remote_url now enforces the e621
  media allowlist and open_remote re-validates every redirect hop; the
  download-task create endpoint and the guest proxy use them, so internal
  addresses (127.0.0.1, LAN, metadata) are rejected with 400.
- Privilege escalation: staff could promote users to staff and demote
  other staff. Role changes across the staff boundary now require an
  admin, matching the account-deletion rules; the Users page hides what
  the backend would refuse.
- SPA-only gating: /api/storage/ and /api/duplicates/* were readable by
  any authenticated account (absolute paths, duplicate groups) while the
  SPA only shows them to uploaders. They now require CanUpload.
- Throttling (REST_FRAMEWORK, env-overridable, counted in Redis):
  anon 120/min, user 600/min, login 5/min, register 20/hour, guest e621
  proxy 60/hour. Login now goes through a throttled view.
- e621 API keys are encrypted at rest with a Fernet key derived from
  SECRET_KEY (apps/accounts/crypto.py); a data migration encrypts existing
  rows and the column widens first. Reads decrypt transparently, legacy
  plaintext still works, and a changed SECRET_KEY reads as 'not
  configured' instead of leaking. Rotating SECRET_KEY now invalidates
  stored keys as well as signed media URLs.
- Hardening: the server refuses to start with DEBUG=False while SECRET_KEY
  is still the development default.

Verified: corrected harness 50/50 (guest visibility, IDOR, signed-URL
tamper/expiry, staged-upload/similarity privacy, role matrix, SSRF),
login throttles at the 6th attempt with 429, anon polling unaffected, the
guest proxy still reaches allowlisted hosts, live e621 auth works with the
decrypted key, and DB rows hold only ciphertext.

AGENTS.md

@@ -47,3 +47,20 @@ Project constraints (do not regress):
   and the server only applies the result via POST /api/files/J-x/optimize/.
 - Do not use imgdd; perceptual hashing is imagehash server-side.
 - Chat/messaging features are out of scope.
+
+Security hardening (do not weaken):
+- e621 API keys are stored Fernet-encrypted with a key derived from
+  SECRET_KEY (apps/accounts/crypto.py); rotating SECRET_KEY invalidates them
+  (and all signed media URLs), so users must re-enter the key.
+- API throttles live in REST_FRAMEWORK (env-overridable): anon 120/min,
+  user 600/min, login 5/min, register 20/hour, e621_proxy 60/hour.
+- Only admins (superusers) may grant/revoke the staff role or delete
+  staff/admin accounts; staff manage regular/uploader accounts only.
+- Storage, duplicates, delete, temp-clear, uploads and downloads require
+  upload rights (CanUpload), not merely authentication.
+- Server-side fetching only happens for allowlisted e621 media hosts via
+  services.validate_remote_url / open_remote (every redirect hop is
+  re-validated); do not call requests.get on user-supplied URLs elsewhere.
+- A repeatable audit harness (permission matrix, IDOR, guest visibility,
+  signed URLs, SSRF, throttles) was used to verify this; formalising it as
+  a test suite is still open in the roadmap.