GHSA-q4vm-pq3q-8wgq

## Impact

Operator session tokens are stored in plaintext in the `operator_sessions` table (the `token` column is the PRIMARY KEY). The session token is a 32-byte random hex value sent directly in a cookie and valid for 24 hours.

- `internal/models/operator.go:61` — `OperatorSession.Token` holds the plaintext token. - `internal/store/sqlite_operators.go:590` — `CreateOperatorSession` inserts `sess.Token` verbatim. - `internal/store/sqlite_operators.go:603,642,681,698` — lookups/updates/deletes use `WHERE token = ?` against the plaintext value.

Anyone who can read the database (backup, snapshot, file copy, or SQL-level disclosure) obtains every active session token and can hijack operator sessions directly, with no further authentication.

This is functionally identical to the plaintext enrollment-token issue fixed in GHSA-ghmh-jhmj-wcmf. API keys (`OperatorAPIKey.KeyHash`) and enrollment tokens (`EnrollmentToken.TokenHash`) already store only a SHA256 hash; session tokens were missed.

## Patches

Store only a SHA256 hash of the session token, mirroring API keys and enrollment tokens: 1. Add a `HashSessionToken` helper (alongside the existing token-hash helpers). 2. Migration to add a `token_hash` column. 3. Update `CreateOperatorSession`, `PromoteOperatorSession`, and `GetOperatorBySession` to write/look up by hash. 4. Drop the plaintext `token` column in a follow-up migration.

Sessions are ephemeral (24h TTL), so all active sessions can be invalidated on deployment — no backward compatibility needed.

## Workarounds

Restrict and encrypt database backups; rotate the operator database. These mitigate exposure but do not fix the underlying storage of plaintext tokens.

## Resources

- `internal/models/operator.go:58-66` - `internal/store/sqlite_operators.go:577-698` - Migration `005_operators.up.sql:27` - Prior related advisory: GHSA-ghmh-jhmj-wcmf