`llm_local`: no `GET /v1/models`, so OpenAI-compatible preflight checks report a healthy sandbox as down

[wehnsdaefflae]

Splitting this out of #59 so the sandbox note is not buried inside a tool contribution.

sandboxes/llm_local serves POST /v1/chat/completions and GET /health, and nothing at GET /v1/models. Read out of app/main.py and app/mocks/openai.py.

That matters more than it looks, because /v1/models is the cheapest liveness probe an OpenAI-compatible client has, and a great many of them use it for exactly that. Point any such tool at the sandbox with a preflight or health-check flag and it reports a perfectly healthy sandbox as unreachable, before a single attack prompt is sent. The failure is silent in the worst way: it looks like the container did not come up.

It is also now inconsistent inside this repository. sandboxes/llm_remote, merged in #65, exposes /health, /v1/models and /v1/chat/completions. So two sandboxes that both claim the OpenAI shape answer differently to the same probe, and a tool configured against one fails against the other.

Two ways to close it, whichever you prefer:

1. Add a minimal GET /v1/models to the mock, returning the one model the sandbox serves. That is a handful of lines and it makes llm_local match llm_remote.
2. Say so in sandboxes/llm_local/README.md — that the models endpoint is deliberately absent and a health check should use GET /health.

Happy to send a PR for either.

[felipepenha]

@wehnsdaefflae Thanks for raising this! Please go ahead with Option 1.

The Gradio UI on port 7860 is a client for both manual and programmatic testing of a chat interface, while the API on port 8000 is intended to function as an OpenAI-compatible API gateway.

Standard red-teaming scanners and SDKs rely on GET /v1/models for preflight liveness checks, so returning a 404 causes them to falsely report a healthy sandbox as down. Adding a minimal GET /v1/models makes complete sense and brings llm_local in line with llm_remote. Looking forward to the PR!