Add SiliconFlow as a built-in driver

[Rex-Gao]

Follows the add-a-provider guide; moved here per the guidance on jev-mcp#39, where this transport originally landed in the wrong layer.

What

• New src/transports/siliconflow.ts following the existing driver shape exactly: name, isConfigured, assertConfigured, create.
• Credential: SILICONFLOW_API_KEY. Auto-detection sits last, after the four existing carriers, so every existing credential set keeps its provider; JEV_PROVIDER=siliconflow forces it.
• Endpoint: POST https://api.siliconflow.cn/v1/systemone with the standard { model, state, questions } envelope and Bearer auth, the same contract the other fetch drivers speak.
• Model mapping: jev-latest maps to semif, the always-current alias SiliconFlow serves (the OpenRouter typesafe/jev-1.13 and Cloudflare typesafe/jev pattern). Other model ids (diffusiongemma, kev-4b) go to the wire verbatim.
• Errors are fixed strings only, matching the sibling drivers' format (SiliconFlow system one API HTTP <status> (reason; N response bytes)); no response bodies or credentials in messages.
• Usage handling follows the OpenRouter/Cloudflare pattern: absent usage reports zeros, a malformed usage container is rejected.
• Registry updates: BuiltinDriver union, the Unknown JEV_PROVIDER list, the no-credentials diagnostic (now names SILICONFLOW_API_KEY), and the trusted provider-name allowlist in ask().
• README: provider list bullet and the JEV_PROVIDER enumeration updated.

Why

SiliconFlow hosts the Jev model family on a System One endpoint and is one of the largest model API carriers in China, which makes it a practical default for callers there where TypeSafe and OpenRouter are hard to reach. The original implementation and live testing came out of jev-mcp#39.

Testing

Hermetic suite passes: 13 tests, with registry precedence extended to five carriers, forced-selection and missing-key cases for siliconflow, a wire test pinning the exact URL/headers/envelope and the jev-latest → semif mapping, error redaction (401 body, malformed 200 body, network throw), and a siliconflow row in the absent-vs-malformed usage matrix.

Notes

• CONTRIBUTING suggests opening an issue first for new built-ins; the redirect on jev-mcp#39 read as that agreement, but happy to split one out if you'd rather discuss built-in vs. driver-package placement.
• jev-mcp would then take this up through resolveTransport once released; its local fetch transports stay as they are, per the consumer-side wiring note.

[jkudish]

Thank you for moving this over to this repo and for the careful driver and tests. I apologize if my redirect from jev-mcp was unclear. I'm keeping built-ins to the current set for now, so I won't merge this for now. It would be welcome as a third-party driver package using the transport interface. If you publish one, a PR linking it from the READMEs of both packages is welcome.

Thanks again!