v0.4.1: keys are routed by their variable, never by their shape

Keys are no longer routed by what they look like.

The variable decides the host. TypeSafe issues apikey_... keys as well as ts_... ones, and key shapes change, so guessing a host from a prefix was always going to break. From this release TYPESAFE_API_KEY goes to TypeSafe, OPENROUTER_API_KEY to OpenRouter, AI_GATEWAY_API_KEY to Vercel AI Gateway, and OPENAI_API_KEY to OpenAI (still opt-in), whatever the key looks like. A key that looks like it belongs elsewhere only earns a hint in doctor, naming the variable to move it to.

The TypeSafe SDK convention still works. TYPESAFE_API_KEY is the generic variable the official SDK reads, so it follows TYPESAFE_BASE_URL and JEV_CODE_PROVIDER to OpenRouter or Vercel the way the SDK does; the OpenRouter and Vercel guides for the SDK work unchanged. Host-specific variables never travel, and the generic key never follows to OpenAI or Ollama.

setup asks which host a pasted key is for, with its best guess as the default: the JEV_CODE_PROVIDER host, else the key's usual shape, else TypeSafe. Both prompts settle when input ends, and a paste holding both answers is read as two.

npx -y @french-castle/jev-code@0.4.1 setup

Re-running setup moves pinned registrations from 0.4.0 to 0.4.1.

Fixed

• A key's shape no longer decides where it is sent; the variable a key sits in does. apikey_... is recognised as a TypeSafe shape for the hint.
• TYPESAFE_API_KEY=sk-proj-... with JEV_CODE_PROVIDER=openai is now refused with "export OPENAI_API_KEY" instead of being sent to OpenAI; the generic key never crosses to a different wire.
• With JEV_CODE_PROVIDER=ollama, a stale TYPESAFE_BASE_URL on another known host is refused like everywhere else instead of carrying Ollama's key and the payload there.
• The setup prompts no longer hang when input ends before Enter.

Full details: CHANGELOG.md. Previous release: v0.4.0.