docs: write the install path for someone who is not the operator (#3271)

FC has no login — no User model, no session auth, nothing. That was a
deliberate call for a single-operator tool and it stays (operator, this
session), but it was nowhere in the docs, and the app stores live Patreon /
SubscribeStar / Pixiv session cookies on accounts that carry a payment
method. Anyone standing this up from the README could reasonably have put it
behind a TLS-terminating proxy and considered it handled.

So the no-auth posture is now stated three times, in the three places someone
decides where to bind the port: README has a "Before you expose it" section
above the install instructions, .env.example explains why there is no auth
variable in it, and the compose header says it before the first service.

SECURITY.md claimed the opposite. It listed "a multi-user sharing ACL —
instances can be shared" among the things worth protecting; there are no
accounts to share between. That was rule 47 applied to a codebase that does
not implement it, and it would have told a researcher FC holds a boundary it
does not. Replaced with the real posture, including that TLS without an
authenticating layer in front changes nothing.

Also corrected, all of it stale rather than wrong-at-the-time:

- EXTENSION_API_KEY was dead config. config.py read it into a field nothing
  consumed; the real key is generated into app_setting on first use and
  managed in the UI. Removed from config.py, compose and .env.example.
- .env.example pointed at docs/superpowers/specs/… — there is no docs/ dir —
  and described the extension key as "lands in FC-3", closed 2026-05-21.
- The /import mount comment described an FC-5 ImageRepo migration run from
  "Settings → Maintenance → Legacy migration", a surface with no frontend.
- README said the extension installs from Settings → Maintenance. It is on
  Subscriptions → Settings.

README is now split: running FC above the line, developing FC below it, with
requirements, first run, the extension, upgrading and troubleshooting on the
running side. First run documents the one real gap it found — a new installer
with a library on disk has no button to import it, only POST
/api/import/trigger, because the manual-scan UI was retired 2026-07-02 when
that stopped mattering for an established install. Filed as #3367.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017QHszn9H8VBvx5Ke8x1hvw

SECURITY.md

@@ -32,29 +32,43 @@ they shape what counts as a serious bug here:
   them, or lets one user of a shared instance read another's is high severity.
 - **An extension API key.** The Firefox extension authenticates to the backend
   with a shared key. Anything that leaks it or lets it be bypassed is a way in.
-- **A multi-user sharing ACL.** Instances can be shared. A bug that lets one
-  account see content another has not shared is an access-control failure, not
-  a cosmetic one.
+- **No authentication of its own.** This is the most important thing on this
+  page. FabledCurator has no login, no user accounts and no permission model —
+  there is no `User` table and no session auth anywhere in the backend. Every
+  HTTP client that can reach the port is the administrator, with full read and
+  write access to everything above, including the stored platform credentials.
+  Access control is entirely the operator's job, done at the network layer.
+  Reports that an unauthenticated caller can reach an endpoint are therefore
+  describing the design; reports that something *crosses the network boundary
+  the operator drew* — an SSRF, a request forgery that rides a browser the
+  operator already has open, a path that leaks state to an origin the operator
+  did not authorise — are in scope and are serious.
 - **Arbitrary media from the internet.** Downloaded files are decoded, hashed,
   thumbnailed and fed to ML models. Anything that turns a hostile file into
   code execution is in scope.
 
 ## Deployment posture — read this before reporting
 
-FabledCurator is designed to run **inside a private network, over plain HTTP**.
-It does not terminate TLS, redirect to HTTPS, or set HSTS; if you want
-transport security, terminate it at your reverse proxy. This is a documented
-design decision, not an oversight.
+FabledCurator is designed to run **inside a private network, over plain HTTP,
+reachable only by its operator**. It does not terminate TLS, redirect to
+HTTPS, or set HSTS; if you want transport security, terminate it at your
+reverse proxy. It also does not authenticate anyone — see above. These are
+documented design decisions, not oversights.
 
-Reports that reduce to "the application is served over HTTP" or "there is no
-HSTS header" describe that decision rather than a vulnerability. Reports that
-an authenticated operator can cause the software to do something destructive
-are usually also by design — the operator is the administrator of their own
-instance.
+Putting this on the public internet, with or without TLS, hands whoever finds
+it your Patreon, SubscribeStar and Pixiv sessions. A reverse proxy that adds
+TLS but not an authentication layer does not change that.
+
+Reports that reduce to "the application is served over HTTP", "there is no
+HSTS header", or "the API needs no credentials" describe those decisions
+rather than vulnerabilities. Reports that the operator can cause the software
+to do something destructive are usually also by design — the operator is the
+administrator of their own instance.
 
 What remains in scope is everything that crosses a boundary the software is
-supposed to hold: between one user and another, between an unauthenticated
-visitor and any of it, and between untrusted downloaded content and the host.
+actually supposed to hold: between untrusted downloaded content and the host,
+between a third-party origin and an operator's open browser session, and
+between the credentials at rest and anything that is not the operator.
 
 ## Supported versions