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

docker-compose.yml

@@ -1,12 +1,21 @@
-# Base compose stack. Uses ${VAR:-default} interpolation throughout so the
-# stack boots with zero config — sane dev defaults baked in. For production
-# deployments, override the defaults via shell env vars or a .env file:
+# Base compose stack, and the install path. Uses ${VAR:-default} throughout so
+# the stack boots with zero config — but those defaults are DEV defaults, and
+# two of them (DB_PASSWORD, SECRET_KEY) are published in this file. Copy
+# .env.example to .env and set them before running this anywhere real.
 #
-#     DB_PASSWORD=...real... SECRET_KEY=...real... docker compose up
+# To run FabledCurator:
 #
-# The dev override (docker-compose.override.yml) is auto-merged when you
-# run `docker compose up` from this directory and switches images to
-# local builds + DEBUG logging.
+#     docker compose -f docker-compose.yml up -d
+#
+# The -f is load-bearing. Without it Compose auto-merges
+# docker-compose.override.yml, which replaces every image: with a local
+# build: and turns on DEBUG logging — the contributor path. Naming this file
+# explicitly skips the override and pulls the published :latest images.
+#
+# FabledCurator has no authentication. Whatever can reach ${PORT} is an
+# administrator, including over the stored Patreon/SubscribeStar/Pixiv session
+# cookies. Do not publish this port beyond a network you trust — see
+# "Before you expose it" in README.md.
 
 # Rolling-deploy safety (Swarm / `docker stack deploy`): update one task at a
 # time, START the new task before stopping the old (zero-downtime via the ingress
@@ -123,18 +132,24 @@ services:
       CELERY_BROKER_URL: redis://redis:6379/0
       CELERY_RESULT_BACKEND: redis://redis:6379/0
       SECRET_KEY: ${SECRET_KEY:-dev_secret_key_not_for_production_change_me}
-      EXTENSION_API_KEY: ${EXTENSION_API_KEY:-}
       LOG_LEVEL: ${LOG_LEVEL:-INFO}
     volumes:
       - ./images:/images
       - ./import:/import
-      # FC-5 legacy migration: bind-mount the host's ImageRepo images dir
-      # under /import (FC's existing filesystem scan picks them up). Read-only
-      # is sufficient — FC copies into /images during the scan. The worker +
-      # scheduler services see the same /import via their own mounts below
-      # because of /import volume reuse. Edit the host path to match your
-      # install before running Settings → Maintenance → Legacy migration.
-      # - /var/lib/imagerepo/images:/import/imagerepo:ro
+      # /import is the staging area for ingesting a library you already have
+      # on disk. Drop files in ./import, or bind-mount an existing directory
+      # under it as below, then trigger the scan:
+      #
+      #     curl -X POST http://localhost:8080/api/import/trigger
+      #
+      # Read-only is sufficient — FC copies into /images during the scan. The
+      # worker + scheduler services mount the same /import so the scan can run
+      # on whichever lane picks it up.
+      #
+      # There is no UI button for this: the manual-scan surface was retired
+      # 2026-07-02 once imports arrived via downloads + the extension, which is
+      # true for an established install and not for a new one. Tracked in #3367.
+      # - /srv/media/my-library:/import/my-library:ro
     depends_on:
       postgres: { condition: service_healthy }
       redis:    { condition: service_healthy }