feat: give each Kanban operator their own account

One OPERATOR_EMAIL and OPERATOR_PASSWORD served the whole factory, so every card
movement recorded the same name and the movement history could not answer who
did what. Traceability was one of the things the project set out to provide.

Accounts live in dtf_local.operators, authenticated with the same scrypt hashing
as customer accounts and with comparable work whether or not the account exists,
so absence is not observable by timing. Administration is a CLI in the API
container, like the schema migration: list, add, password, disable, enable.
Passwords are read from the terminal rather than an argument so they stay out of
shell history and the process list, and disabling deletes that operator's open
sessions instead of leaving them valid for the rest of the eight-hour window.

Migration is the part that could hurt: an empty table means 503 and a factory
locked out of its Kanban. OPERATOR_EMAIL and OPERATOR_PASSWORD seed the first
account, and only when that email is absent, so a password changed through the
CLI survives a redeploy carrying a stale environment variable. The first attempt
at this silently did nothing, because db-init receives its own small environment
and had neither variable; both compose files now pass them to it.

Verified against a running stack: bootstrap seeds the existing credential, that
credential still logs in unchanged, a second operator authenticates separately,
wrong passwords and unknown accounts are rejected alike, and disabling revokes
an open session immediately.

Roles are left out on purpose. The separation of duties the meeting described
governs rework authorisation, which this system does not implement, so a role
model would have no consumer to serve.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

ROADMAP.md

@@ -274,12 +274,30 @@ workaround — but staying on it indefinitely is not a posture. Upgrading is an
 change rather than a file swap and needs its own browser testing, so it is
 deliberately not bundled here.
 
-### `[ ]` 2.8 — Single shared operator credential `(F12)`
+### `[x]` 2.8 — Single shared operator credential `(F12)`
 
-One `OPERATOR_EMAIL`/`OPERATOR_PASSWORD` for the whole factory; `movements.operator`
-records the same name for everyone. The meeting asked for traceability, and the old
-`kanban/main.py` explicitly designed separation of duties (Mayana classifies,
-Thales/Alexandre authorise). Needs real per-person accounts with roles.
+Accounts now live in `dtf_local.operators`, one per person, with `movements.operator`
+and `order_files.created_by` recording who actually acted. Administered from the API
+container with `python -m local.operators` (list, add, password, disable, enable);
+passwords are read from the terminal so they never reach shell history or the
+process list, and disabling revokes open sessions immediately rather than leaving
+them valid for the rest of the eight-hour window.
+
+Migration was the risk, since getting it wrong locks the factory out of the Kanban.
+`OPERATOR_EMAIL`/`OPERATOR_PASSWORD` seed the first account, once: a password
+changed through the CLI is never reverted by a stale environment variable on the
+next deploy. The first attempt did not work — `db-init` was not given those
+variables in either compose file, so no account would have been created and login
+would have failed closed with 503. Both files now pass them to the migration job.
+Verified end to end: the unchanged credential still logs in, a second operator
+authenticates separately, wrong passwords and unknown accounts are rejected, and
+disabling ends access at once.
+
+**Roles are deliberately not included.** The meeting described separation of duties
+for rework authorisation (Mayana classifies, Thales or Alexandre authorise), but the
+rework feature does not exist in this system, so there is nothing for a role to
+gate. Building an authorisation model with no consumer would be guesswork. Add roles
+with the feature that needs them.
 
 ### `[~]` 2.9 — TLS is terminated outside the repository `(F13)`