Report an unroutable classifier cell as no_route

[rabeckett]

Problem

/classify returned invalid_request when none of the offered models appeared in the classifier routing cell. That is not a caller mistake. The request is well formed and the router simply has nothing it can serve, which is exactly what no_route means.

/route already reports the same condition as no_route, and RoutingTable.route documents the rule the service follows:

Raise RoutingError for invalid requests or NoRouteError when no supported offered candidate has sufficient context capacity.

Classification was the one path that had drifted from that rule.

Why it matters

The asymmetry forced callers to branch on the endpoint to recognise a routine outcome. A client that handled no_route correctly for /route would misreport the identical situation from /classify as a contract violation, sending operators to look for a bug that does not exist.

This was found from the consuming side. A caller offering a model pool with no overlap against the router's tables saw "the router rejected the classify request" when the honest answer was "nothing here fits". Fixing it here means callers need no local mirror of the router's catalogue to produce a correct diagnosis, and the router stays the single authority on what it can serve.

Change

create_classification_plan raises NoRouteError instead of ClassificationError for an empty intersection.

Malformed input is unchanged and still invalid_request, covering a missing authored user message and an omitted effort for a model that requires one. Those are genuine caller errors with something to fix.

The CLI exits 3 rather than 2 for this case, which matches route and required no CLI change since NoRouteError is already handled ahead of the ValueError catch.

Contract coverage

The existing classify-no-supported-choice case offered models: []. The ordinary production shape of this failure is a non-empty pool whose entries are all unrecognised, and that went unrecorded, which is how the inconsistency survived. Added classify-unrecognised-choices to cover it.

openapi.yaml now documents the no_route outcome on /classify, mirroring the wording already used for /route.

Version

Bumped to 0.1.1 across pyproject.toml, __init__.py, openapi.yaml and the Dockerfile ARG, with the recorded discovery fixture updated to match. This is a behaviour change to a published HTTP contract, so it should not ship under the released 0.1.0.

Validation

• pytest excluding docker: 409 passed
• ruff format --check, ruff check, ty check: clean
• Behaviour confirmed against a real container before and after, using the synthetic tables. Unrecognised pool now returns 422 no_route. A pool with partial overlap still returns 200 and ranks only the recognised entries.

Docker and release-marked suites are left to CI. They could not run in my sandbox because uv cannot reach PyPI from here.