v0.45.1 — the gateway boots again

If you run Chimera headless in Docker, v0.45.0 does not start. Upgrade to this.

The image installs .[full], which does not include the desktop extra, so the container running the 24/7 gateway has no FastAPI. v0.45.0 put from chimera.api.usage import … on the cron path — and importing a leaf executes the package __init__, which eagerly re-exported build_api_app. A JSONL reader dragged in the whole web stack, and the container crash-looped on ModuleNotFoundError: No module named 'fastapi'.

Found by a deployment, not by us. The development environment has FastAPI, so the import succeeds and the fault is invisible to every test that runs — none of 2,945 could see it.

Fixed at the cause, not the symptom

Adding desktop to the image would have worked. It would also have made the image heavier, contradicted the extra's own documented reason for existing — "the core CLI/gateway never needs it" — and left the trap armed for the next leaf import.

chimera/api/__init__.py now resolves its re-exports lazily. chimera.api.usage, .roles, .sessions, .posture and .config_api cost what reading a file should cost. chimera app still needs the extra and still fails loudly without it.

That docstring's claim had been false for a while: five leaf modules with nothing FastAPI-shaped in them, all reached by the CLI, each pulling the web stack behind it. What v0.45.0 changed was putting one of them on the unattended boot path, where it stopped being latent.

The test that would have caught it

It runs in a subprocess with fastapi made unimportable, and its first assertion is that the block works. Without that, every check after it would pass in an environment that has FastAPI — which is exactly how this shipped.

Verified end to end besides: a clean .[full] install, no desktop, and serve --cron reaches gateway on http://127.0.0.1:8765 instead of a traceback.

Everything else is v0.45.0 — see those notes.