feat(larql-cloud): outbound LLM clients (OpenAI-compatible + Bedrock) and a cloud proxy

[gburd]

Adds larql-cloud: outbound LLM clients, so larql-server can act as a caller of OpenAI-compatible services and AWS Bedrock, not only as an answerer of that API.

Purely additive — one new crate plus its CI workflow. No existing code is touched.

What it is

larql-server already speaks the OpenAI API as an answerer (crates/larql-server/src/routes/openai/). This is the mirror: one trait, CloudClient, exposing the three operations a database front-end needs to delegate to a cloud model.

trait CloudClient {
    async fn infer(&self, req: InferRequest) -> Result<InferResponse, ProviderError>;
    async fn embed(&self, req: EmbedRequest) -> Result<Vec<Vec<f32>>, ProviderError>;
    async fn chat(&self,  req: ChatRequest)  -> Result<ChatResponse, ProviderError>;
}

Providers:

Backend	Auth	Model name shape
OpenAI	OPENAI_API_KEY bearer	gpt-4o-mini
Exoscale SKS-LLM	EXOSCALE_API_KEY bearer	meta-llama-3.1-8b
Together AI	TOGETHER_API_KEY bearer	meta-llama/Llama-3-…
Fireworks	FIREWORKS_API_KEY bearer	accounts/fireworks/…
vLLM / llama.cpp	none	server-defined
ollama	none	qwen2:1.5b
AWS Bedrock	bearer token or SigV4	anthropic.claude-…, incl. cross-region inference profiles

Also larql-cloud-proxy: a binary exposing /v1/infer, /v1/embeddings, /v1/chat/completions and a /v1/stats shaped so an existing client's registration probe succeeds, with /v1/walk and /v1/describe answering 501 (there is no vindex behind a cloud API). That lets a client point at either a real vindex or a hosted model without knowing which.

Why upstream rather than in my fork

The crate exists because I needed it for pg_infer, but nothing in it is pg_infer-specific — it is a general outbound client for this workspace, and the proxy is the piece that makes "vindex or hosted model, same wire protocol" work for any client. Carrying it in a fork indefinitely means the workspace has two divergent answers to "how does larql call out to a model".

Happy to drop the proxy binary and land only the library if you'd rather keep the binary surface smaller.

Feature gating

default = ["openai", "bedrock"]. openai is dependency-free; bedrock gates the SigV4 dependencies (hmac, sha2, hex). Both build and test independently — CI checks all four combinations, since a no-default build is what proves the gating is real.

CI

Every crate here has its own workflow, so this adds larql-cloud.yml, modelled on larql-core.yml (the closest match: portable, no weights, no platform backend). Linux + Windows on PRs, macOS additionally on main, following the rationale larql-core.yml documents about macOS queue waits.

Every command in the workflow was run locally on the pinned 1.98.0 before committing, and one failed:

clippy -p larql-cloud --no-default-features --all-targets -- -D warnings

BedrockClient::send takes service for the SigV4 signing scope, read only by the cfg(feature = "bedrock") arm of the auth match — so with the feature off it is an unused variable. A latent warning that would have made the workflow red on its first run. Fixed with a cfg'd allow(unused_variables) rather than cfg-ing the parameter out of the signature, so both builds keep the same call sites.

Verification

Pinned toolchain (1.98.0), full feature matrix: fmt, 5 check variants, 2 clippy -D warnings variants, 4 test variants — all pass. 13 tests including a proxy integration test that binds loopback only (no network, no credentials, hermetic).

[gburd]

Heads-up on the two red checks (cargo-audit, cargo-deny · advisories) — they are not from this PR.

RUSTSEC-2026-0285 is a rustls advisory published 2026-09-14, a few hours after main's last quality.yml run (23a56db1, 2026-09-14T11:45Z), which is why main still shows green. main's own lockfile pins rustls 0.23.39; the advisory wants >= 0.23.45.

This PR's Cargo.lock is byte-identical to main's:

$ git diff --quiet upstream/main..<this branch> -- Cargo.lock && echo IDENTICAL
IDENTICAL

So any PR opened against main right now inherits the same two failures, and a rustls bump is needed on main independently of this change. Happy to add that bump here if you'd like it bundled, but it seemed wrong to fold an unrelated dependency change into a Nix fix.

[gburd]

Follow-up on the two red checks: I've opened #481, which bumps rustls 0.23.39 → 0.23.45 (lockfile only) and clears RUSTSEC-2026-0285.

On that branch cargo-audit and cargo-deny · advisories both pass. Merging it first (or rebasing this branch onto it) turns these two green here as well — they are inherited from main, not introduced by this PR.