Sign in to Web with the Core key and rename its configuration

[SaladDay]

Sign in to the Web console with the Core key, and rename the Core key configuration. This is the backend P2a batch combined with the frontend login change (#120), merged as one PR so main never has mismatched login contracts.

Backend

• Console authentication:

  • GET /console/auth → {"mode":"login"|"authenticated"}.
  • POST /console/auth/login with {"core_key"} → 200 and an HttpOnly, SameSite=Strict session cookie. Errors: 401 wrong key, 400 malformed, 415 non-JSON, 429 with Retry-After, 503.
  • POST /console/auth/logout.
  • Removed: account/password, first-run setup, the account store, legacy Basic authentication, CORE_CONSOLE_AUTH_MODE and CORE_CONSOLE_STATE_DIR.
  • The key is compared in constant time and never logged or echoed. Only failed attempts count toward the 10-per-minute limit, so the correct key always signs in. Web refuses a Core key shorter than 32 characters.

• Audit actor: Web operations carry the display-only label console. The label is caller-declared and is never used for authorization.

• /console/config: no longer returns sandbox_admin or api_keys.

• Configuration renames:

  Before	After
  admin/sandbox-admin.key	admin/core.key
  admin/digests.json	admin/core-key-digests.json
  AGENTS_API_SANDBOX_ADMIN_DIGESTS_FILE	AGENTS_API_CORE_KEY_DIGESTS_FILE
  CORE_CONSOLE_ADMIN_TOKEN_FILE	CORE_CONSOLE_CORE_KEY_FILE
  installer --admin-token-file	--core-key-file

  Old names fail at startup with a message naming the new one.

• Docs: new docs/getting-started/operations.md#core-key covering location, scope, privacy, rotation and upgrade renames; install, configuration and API docs updated.

Frontend (#120)

• The login page takes only the Core key, trims it, and handles errors by status code only.
• A missing sandbox_admin is treated as granted.
• The audit actor wording matches the backend.
• Fixtures and acceptance tests are updated.

Validation

• Backend: console, cmd/server and api tests; 129 installer tests.

• Real check: a real Core, console and PostgreSQL covering sign-in, the lockout fix, the /core/v1 proxy with and without a session, Core-key direct access to /core/v1 (200) and to /v1 (401), old-name startup failures, and the rotation steps.

• Frontend: typecheck, 327 unit tests and 15 browser acceptance tests passed on the frontend side.

• Gate: full make check (server mode) passed on the final combined head 98015ce6: the backend rebuilt on main cc4acc1f, then the frontend login commits, then a merge of main 3c31ade9. Playwright browser cases were skipped on the server (Chrome unavailable; user-approved skip). The frontend ran the 15 browser acceptance tests, including Core-key sign-in, the lockout and a fresh install, on the same head.

• Review: an independent security-focused blind review by a fresh Claude subagent found no P0/P1. Its findings were small and verified by tests and the gate, without a second review round:

  • P2: a global sign-in lockout;
  • P3: key strength, audit-label wording and rotation steps.

  Nonblocking: the concurrent sign-in worker bound can briefly answer 429 "busy" during a flood.