feat(web): show Codex plan usage in header

[JackStuart]

Previously the header bar only showed Claude usage (and didn't specify that it was Claude). With this change I've added Codex and made the usage clearer

Before

After

[Ark0N]

Thanks, merged. The before/after shots made the case on their own: the old chip never said whose limits it was showing, which stops being a detail the moment you run more than one CLI.

Verified here rather than taken on trust:

• codex app-server --stdio really does answer account/rateLimits/read after initialize on codex-cli 0.147.0, and comes back in about 150ms.
• Rendered the two-row chip in a real 1440px browser: 33px tall inside a 48px header, no overflow, both rows colour-coded as intended.
• typecheck, lint, format:check, check:public-assets, check:frontend-syntax and the full npm test gate all pass on the merge with current master.

Three things I noticed, none of them blocking:

1. The poll is unconditional. Once codex is on PATH the server spawns codex app-server every five minutes whether or not anyone has a Codex session open or the chip switched on. It is read-only and cheap, so this is a tidiness point rather than a problem, but gating it would be nicer.
2. parseCodexRateLimitsResponse accepts only the 300 and 10080 minute windows. A free-tier account here reports windowDurationMins: 43200, so it is dropped and the Codex row simply does not appear. That is consistent with the 5h/7d labels, so I think it is the right call, just worth knowing it is the behaviour.
3. CODEX_BINARY = process.platform === 'win32' ? 'codex.exe' : 'codex' makes this the only one of the seven resolvers that does that, and Codeman needs tmux anyway, so it is inert either way. Harmless, just inconsistent with its siblings.

Thanks also for updating CLAUDE.md and architecture-invariants.md in the same PR. That is the part contributors usually skip and it is the part that keeps the next person from re-deriving all of this.