feat(website): the queen lives at /#/queen on the existing site

[gHashTag]

Closes the second deployment. apps/queen-web had its own Railway service and its own domain, and that service has never deployed successfully — 13 of 13 failures. This puts the queen on the site that is already live.

What this is

A new lazy route /#/queen on apps/website, ported from apps/queen-web.

No new dependency. The original pulled @tanstack/react-query in for four panels; plain hooks do the same work in a 6.44 kB lazy chunk, so nobody who is not looking at the queen pays for her.

Four defects fixed rather than carried across

#	in apps/queen-web	here
1	The three kingdom tabs never worked — setActiveTab was never called, so the highlight sat on Brain whatever you clicked, and the <Link to="?kingdom=…"> targets were read by nothing	buttons that select what the page renders
2	Every panel called res.json() without checking res.ok. On static hosting /api/status returns the SPA fallback — HTML with a 200 — so panels died on a JSON syntax error that reads like a bug in the queen	status and content-type checked; the real cause is named
3	episodes?.slice() on whatever came back — a non-array response crashed the page on that line	shape checked before use
4	Missing values rendered as 0, or as ... forever	they render as —, and an unreachable brain is stated in a banner

That last one is the point of the change. An empty dashboard and a healthy queen with nothing to report looked identical. Now the page says which one it is.

The brain is not part of this

The backend is a separate service. This page reads VITE_QUEEN_API at build time, falls back to localhost:8080 in local dev, and otherwise says plainly that no address is configured. Wiring the brain is the next piece of work, and it is not blocked by this.

Verification

Build: 522 modules, exit 0, Queen-*.js 6.44 kB + Queen-*.css 3.12 kB, both lazy.

Rendered page checked in a browser, not just built:

• offline banner shown, naming the four endpoints and what was actually tried
• metrics read —, not 0
• improve button disabled, with "Unavailable — no brain" as its reason
• clicking Body switches both the highlight and the content — the defect in row 1

[gHashTag]

Follow-up: the face and the brain were never connected

Pushed 5271bdd3b. I read src/background_agent/server.zig instead of assuming what the backend offers. Its entire surface is:

route	auth
/health → {"status":"ok"}	none
/api/containers	token required
/api/sessions	token required

The queen's panels called /api/status, /api/episodes, /api/improve and /api/pipeline, and rendered trinity_signature, improve_cycles, uptime_seconds, env_status, swarm_active.

The brain serves none of those routes and returns none of those fields. Five metrics out of five could never have been filled — not by a better deployment, not by any deployment. That is why deploying the queen was never going to produce a working page, independently of the four build failures.

So this PR now renders what is actually measurable:

• Liveness shows what /health really returns, and says outright that it carries no counters and no uptime.
• The improve button is gone. It could only ever have errored. The panel states that the route is missing from the brain and that restoring it is a change to server.zig, not to this page.
• Containers and Sessions replace Episodes, and a 401 is reported as "requires a token" rather than as an unreachable brain — those are different facts and were previously the same message.

Verified after a forced reload: the first check served a cached bundle and showed the old endpoint list, which would have passed as a green check.