GhostBus v0.5.2 — security hardening

Security hardening — closing the gaps a cold review (and common sense) flags before hosted workspaces serve paying strangers.

What changed

• Hosted token enforcement is now ON by default. Every workspace on the hosted server enforces per-agent tokens unless the operator explicitly opts out with GHOSTBUS_REQUIRE_TOKENS=0 — and opting out prints a loud startup warning. (Before: enforcement was opt-in.)
• Admin-key floor: the hosted server refuses to start with an admin key under 16 characters (a missing key was already refused). The admin key is root for the deployment; docs now specify root-only file storage (chmod 600) and rotation.
• Isolation tests: the suite now proves cross-workspace keys get 401, admin routes reject non-admins (incl. list), and agent actions are rejected without/with a wrong token and accepted with the issued token — over real HTTP against the hosted server. 47 → 51 checks, all passing; serverless 6/6; both demos green.
• Single-relay warnings: the plain HTTP relay now warns loudly at startup when it has no key (it listens on all interfaces) or runs without token enforcement.
• Docs: new "Security & deployment hardening" section in docs/hosted.md — HTTPS is required for public deployments (reverse proxy or a named Cloudflare tunnel; a quick tunnel is not for paid use), key handling, scheduled export backups.

What did NOT change — local/stdio trust model and semantics, core storage (memory/JSON file), and the roadmap: a networked multi-writer store remains future work, deliberately. The serverless pack keeps its env opt-in posture, now documented as such.

The open surfaces, stated plainly: /health and a counts-only /probe (queued / needsApproval / agent counts — no message, task, or file content) stay unauthenticated for monitoring and wake hooks, as documented. All data routes require the workspace key.