Allow runtime facade model passthrough

[yorkew-east8]

Summary

• allow provider-bound Runtime LLM Facade tokens to request any non-empty model from their pinned provider
• keep the provider fixed by the token; model passthrough never selects a different provider
• honor an explicit provider/model wire API override and otherwise use the pinned provider default wire API
• let the upstream provider decide whether an unregistered or unsupported model is valid, preserving its existing non-2xx response handling
• preserve providerless compatibility tokens, including Claude/generic-provider fallback and empty-provider token issuance
• retain providerless token model scope and strict configured model/provider resolution
• update user, design, and E2E strategy documentation

Compatibility and scope

Only provider-bound Runtime LLM Facade request resolution is relaxed. Missing models still return 400. Token ownership, sandbox lifecycle, inbound wire API checks, provider pinning, authentication/header handling, and response forwarding remain unchanged.

Providerless compatibility tokens continue to use the behavior from main: a token model remains an authorization scope when present, Claude/generic-provider fallback may issue a token without provider/model, and configured model/provider resolution remains strict. If a provider-bound token references an absent or disabled provider, resolution falls back to the original strict resolver so existing error behavior is preserved.

Token creation, Claude runtime configuration, application wiring, schema, protobuf, UI, drivers, scheduler, and LLMService behavior are unchanged relative to main.

Tests

Focused regression coverage includes:

• provider-bound alternate and unknown model passthrough
• pinned-provider routing when a model is bound only to another provider
• provider/model wire API override and provider default fallback
• Anthropic provider routing
• upstream model error forwarding
• providerless token model mismatch rejection
• providerless Claude compatibility-token issuance
• missing/disabled provider fallback and resolver store errors

Verification

Passed locally for the production change:

• go test ./pkg/llms/... ./pkg/agentcompose/proxy ./pkg/agentcompose/app ./pkg/agentcompose/adapters ./pkg/runs
• scoped golangci-lint for changed Go packages: 0 issues
• task build

GitHub CI passed the complete lint, Go test, coverage, Runtime SDK, Scheduler runtime, Darwin/Linux build, image build, and full-image Docker smoke matrix for the production change. The final commit only clarifies README wording from "Legacy compatibility tokens" to "Compatibility tokens".

[monkeyscan]

PR Title: Allow runtime facade model passthrough

Commit: 9867aec

本次 PR 围绕 Runtime LLM Facade 引入两项核心改动：

1. 允许 provider-bound token 的模型透传：当 facade token 包含非空 provider_id 时，runtime 请求中的模型名不再受 token 签发时的默认模型限制，而是直接透传给该 provider，由上游决定是否接受。这通过将 ResolveRuntimeLLMFacadeTarget 改为内部函数 resolveRuntimeLLMProviderTarget（返回 (ResolvedTarget, bool, error)）并在 resolveRuntimeLLMTarget 中优先走 provider 直达路径实现。

2. 保留 providerless 兼容 token：为 Claude 等兼容路径，当无法从配置解析出具体 provider/model 但存在 Anthropic API key 时，允许签发 provider_id 和 model 均为空的 token。NewFacadeToken 移除 provider 必填校验。Providerless token 在 runtime 请求时保持原有的 env/config 解析行为，并在 runtime_llm.go 中增加了 model scope 校验（token.ProviderID == "" && token.Model != "" && token.Model != model 时返回 403）。

关键文件变更：

• pkg/llms/token.go：移除 providerID 非空校验，token_test.go 同步删除旧测试。
• pkg/llms/runtimefacade/config.go：ensureSessionClaudeConfig 在 optional error 且存在 anthropic key 时签发空 provider token。
• pkg/llms/resolver.go：新增 ResolveRuntimeLLMTarget，provider+model 均非空时优先走直达 provider 路径，否则回落到 resolveRuntimeLLMTargetWithEnv。
• pkg/agentcompose/proxy/runtime_llm.go：增加 providerless token 的 model mismatch 校验和 provider mismatch 校验。
• 测试与文档同步更新。

整体评估：逻辑清晰，兼容路径与透传路径的边界明确，安全校验（provider mismatch、model mismatch）保持完整，未发现明显缺陷。

[monkeyscan]

PR Title: Allow runtime facade model passthrough

Commit: d196093

本次 PR 仅修改了 README.md 中的一处文档措辞：将 "Legacy compatibility tokens" 改为 "Compatibility tokens"，去掉了 "Legacy" 一词。这是一个纯粹的文档说明性调整，不涉及任何代码逻辑、配置或行为变更，整体风险极低，未发现可操作的缺陷。