[Feature] Multi-user accounts + role-based access control for the API/dashboard

Summary

Spacebot's API auth today is a single shared bearer token (api_auth_middleware in src/api/server.rs:346-376). There are no users, no roles, and no audit trail. As soon as more than one person operates an instance — or it's exposed beyond localhost — anyone with the token can read all channels, edit all secrets, run any worker, and rewrite identity files.

Current state

• src/api/server.rs:351 — middleware checks an optional state.auth_token against an Authorization: Bearer … header
• src/api/server.rs:351-353 — if no token is configured, all auth is skipped (see also #356 which proposes failing closed)
• All routes share the same single principal; no per-route or per-action authz
• The dashboard frontend is unprotected (src/api/server.rs:322 "Static file handler for frontend (unprotected)") — only API calls go through the middleware

Proposed change

A basic local user system, opt-in via config:

• New SQLite migration: users(id, username, password_hash, role, created_at) (argon2/bcrypt for hashing)
• Roles to start: owner, admin, editor, viewer
• Sessions via HTTP-only Secure cookies (configurable TTL); existing Authorization: Bearer … path retained for scripts/CLI as PAT-style tokens scoped to a role
• New auth middleware variant that resolves the principal (user or PAT) and attaches it to the request extensions
• Permission matrix per surface area: channels, agents, secrets, settings, cron, memory, workers, identity files
• auth.mode = single-token | multi-user | disabled in config — disabled retains today's silently-open behavior only when explicitly opted into (so #356 stays addressed); single-token preserves backward compat; multi-user enables the new system
• First-run bootstrap: create an owner account via CLI (spacebot user create --owner) or a one-time setup token

Out of scope (follow-ups)

• SSO / OIDC
• Per-channel ACLs (start with global roles)
• Audit log of mutations (separate issue worth filing)
• Per-agent secret namespacing — already tracked in #354

Open questions

• Should internal cortex/worker calls go through the same middleware with a synthetic system principal, or bypass it as today?
• Where should sessions be stored — same SQLite, or a dedicated key-value store?
• Should the dashboard's static bundle stay public, or also be gated behind auth?

Related

• #356 — "API authentication is silently skipped when auth_token is not configured" (this proposal subsumes the fix when auth.mode = multi-user)
• #354 — per-agent secret namespacing (orthogonal but complementary)

Start with the auth middleware and dashboard handler in src/api/server.rs:322 and 346-376, then trace the config and CLI entry points before deciding how the SQLite migration fits. Resolve the open questions around internal principals, session storage, and dashboard gating. Done means the selected auth modes, user roles, sessions or PATs, permission surfaces, and owner bootstrap are defined while preserving the documented single-token behavior.