docs: document OmniRoute OpenAI-compatible setup

[diegosouzapw]

Proposal

Add a copy/paste-safe OmniRoute example to the existing
docs/local-openai-compatible-providers.md guide.

Claw already has the required generic runtime behavior:

• OPENAI_BASE_URL configures the OpenAI-compatible endpoint;
• the client appends /chat/completions without duplicating a full endpoint;
• OPENAI_API_KEY is sent as a Bearer token;
• the local/ prefix selects the OpenAI-compatible transport and is removed before the model ID is sent;
• the existing client supports SSE and OpenAI-compatible tool-call response shapes.

The proposed documentation would cover:

export OPENAI_BASE_URL="http://localhost:20128/v1"
export OPENAI_API_KEY="replace-with-an-omniroute-api-key"

curl -sS "$OPENAI_BASE_URL/models" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  | jq -r '.data[].id'

claw --model "local/auto" prompt "Reply exactly HELLO_FROM_OMNIROUTE"

The /v1 suffix matters because Claw appends /chat/completions. The full proposal also explains
Docker/host reachability, model IDs containing slashes, and that live streaming/tool compatibility
depends on the selected model/provider behind OmniRoute.

Verification completed

• cargo test --workspace: 1,415 passed, 0 failed, 1 ignored;
• cargo fmt --all --check;
• cargo clippy --workspace (passes with pre-existing warnings);
• documentation source-of-truth and release-readiness checks;
• focused endpoint, streaming, and multiple-tool-call tests;
• real Claw binary against a sanitized local OpenAI-compatible mock;
• git diff --check.

Patch availability

A docs-only patch is prepared locally as one commit (de857038b2f9ff9b319132e2241549e86215c351),
changing only docs/local-openai-compatible-providers.md (+37 lines).

I attempted to create/update a GitHub fork for the normal pull-request flow, but GitHub locked the
fork immediately and rejected both Git push and REST ref creation. If maintainers agree with the
documentation direction, I can open the PR as soon as GitHub permits a writable fork, or provide the
exact patch in the preferred form.

[1716775457damn]

Good catch. The /v1 suffix handling (Claw appending /chat/completions) is a common gotcha that trips up new users — surfacing it explicitly in the docs saves debugging cycles. One suggestion: also note that OmniRoute's model listing endpoint (/v1/models) uses OpenAI-compatible response shape, so jq '.data[].id' works out of the box. The proposal is complete and self-contained; +1 on adding this to docs/local-openai-compatible-providers.md.

[1716775457damn]

Thanks for the documentation PR — the OmniRoute setup guide will be helpful for users getting started with OpenAI-compatible endpoints.