jcode run --json reports "provider": "openrouter" for --provider openai-compatible

Summary

jcode run --json reports "provider": "openrouter" when the session is actually running on --provider openai-compatible.

Reproduction

JCODE_OPENAI_COMPAT_API_BASE=http://127.0.0.1:8020/v1 \
OPENAI_COMPAT_API_KEY=EMPTY \
jcode run --provider openai-compatible -m <model> --json 'say ok'

Output (0.68.0):

{
  "session_id": "session_jaguar_...",
  "provider": "openrouter",
  "model": "<model>",
  "text": "\n\nok",
  ...
}

The request does go to the configured OpenAI-compatible endpoint — only the reported label is wrong. My guess is that the id leaks from the implementing crate, since the OpenAI-compatible runtime lives in crates/jcode-provider-openrouter-runtime/.

Why it matters

--json is the machine-readable surface, so this is the one place the label is consumed by programs rather than read by a human. Anything that aggregates runs by provider — cost attribution, per-provider success rates, routing/debugging in a harness — silently misfiles openai-compatible sessions as OpenRouter, and a run against a purely local endpoint gets attributed to a paid third-party service. It is also confusing on its own terms: nothing the user typed mentioned OpenRouter.

Expected: "provider": "openai-compatible" (or the named provider profile in use).

Environment: jcode 0.68.0, Linux x86_64.

Start with the jcode run --json output path and inspect crates/jcode-provider-openrouter-runtime/, where the OpenAI-compatible runtime is implemented. Reproduce the command with --provider openai-compatible and check where the provider label is selected. Done means the JSON output reports openai-compatible or the active named provider profile without changing the configured request endpoint.