GhostBus v0.5.7 — hardening round 6: tokens & serverless parity

Hardening round 6 — token lifecycle, and the serverless pack had quietly drifted.

Four real divergences between the Node servers and the Netlify build, all closed:

1. Token enforcement defaulted OFF in the serverless pack — it kept the pre-v0.5.2 opt-in semantics. A tokenless act returned 200 where the hosted server returns 400. Default is ON now, with the same GHOSTBUS_REQUIRE_TOKENS=0 opt-out spelling.
2. No admin-key floor serverless — a 5-character admin key was accepted. Now refuses <16 chars at construction, matching the Node servers.
3. Rotate-key, export, and import did not exist serverless — a leaked serverless workspace key could only be answered by deleting the workspace. All three routes now exist with Node semantics.
4. Agent-token rotation was MCP-only — no REST route anywhere. POST /api/agents/rotate-token now exists on the relay, hosted, and serverless handlers; rotation requires the current token and the old token fails on the very next request (pinned over real HTTP).

Verified already safe, now pinned: rotation replaces hashes and persists before replying; every credential is crypto-random 192-bit (format-asserted, values never printed); credentials appear only in their one-time issuance replies — never in the event log (readable by all workspace members), errors, audit lines, or board payloads; exports carry SHA-256 hashes only and are not credential-equivalent.

Documented, deliberately not built: tokens don't expire (rotation is the revocation story — full runbook in SECURITY.md), and the authorization model is single-scope by design at pilot stage (workspace key = full access to its one workspace). Both stated plainly in SECURITY.md rather than papered over.

Verified: 70 checks (was 69); serverless suite doubled 6 → 12 to hold the parity; both demos.