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>

compose.local.yaml

@@ -95,6 +95,12 @@ services:
       DATABASE_ADMIN_URL: postgresql://${POSTGRES_USER:-dtf_local}:${POSTGRES_PASSWORD:-local-database-only}@db:5432/${POSTGRES_DB:-dtf_local}
       APP_DB_USER: ${APP_DB_USER:-dtf_app}
       APP_DB_PASSWORD: ${APP_DB_PASSWORD:-local-app-database-only}
+      # The migration job seeds the first operator account from these, so an
+      # existing deployment keeps its Kanban login after the accounts table
+      # lands. Without them there would be no account at all and login would
+      # fail closed with 503.
+      OPERATOR_EMAIL: ${OPERATOR_EMAIL:-operator@example.test}
+      OPERATOR_PASSWORD: ${OPERATOR_PASSWORD:-local-operator-only}
     networks: [local]
     depends_on:
       db: {condition: service_healthy}