Identity tokens live in localStorage, where any script on the origin can read them

Raised by codex while reviewing the portal shell. It is **not** new to the portal — `src/frontend/src/main.tsx:499` has always done it, and the portal inherited the pattern through `src/shared/api.ts`.

An identity token is described in `Credentials.cs:10` as "slug + HMAC, deterministic, eternal". Storing one in `localStorage` means:

- any script running on the panel's origin can read it, so a single XSS anywhere in **either** frontend entry hands over a permanent credential;
- signing out clears this browser's copy and revokes nothing — the token is still valid everywhere, forever, because it is derived rather than issued;
- it is durable by design, so it survives the browser being closed and outlives any session policy.

This is precisely the flaw the session work in #9 was built to fix: passwords produce an httpOnly cookie the runtime honours only alongside `X-Cielo-Panel`, which script cannot read. The token path is the legacy fallback that was left in place for agents, the CLI, and installs that predate passwords — and it quietly reintroduces the property the cookie exists to avoid.

## Options

1. **Exchange, don't store.** Accept the token once at sign-in, hand it straight to the runtime, and have the runtime mint a normal session cookie. The token then never rests in the browser at all. This is the one I would defend: it keeps the upgrade path working and removes the storage entirely.
2. **Keep it in memory only.** `shared/api.ts` now has an in-memory token that storage falls back to, so most of this already exists — dropping the write would mean re-entering the token after every reload, on the installs least able to tolerate friction.
3. **Make tokens revocable**, which turns "eternal" into a policy question. Larger, and does not stop the read.

Not urgent enough to block the portal, and dishonest to leave unfiled: it is a known-shape weakness sitting in the sign-in path of the surface every end user will now touch.

Trace the token flow from src/frontend/src/main.tsx:499 through src/shared/api.ts, and read Credentials.cs:10 plus the session behavior described in #9. Determine how the legacy sign-in path should hand the token to the runtime without browser storage, then verify that session authentication still works and no identity token remains in localStorage.

Written by the indexing model from the issue text.