feat(providers): add canonical free provider directory

[HaydernCenterpoint]

Summary

• add a canonical directory for free provider presets
• derive and register directory entries consistently
• cover registry parity

Tests

• bun test tests/provider-registry-parity.test.ts

Summary by CodeRabbit

• New Features

  • Added a directory of free and reference providers with access, verification, documentation, and model availability details.
  • Expanded provider discovery and preset information shown by the application.
  • Added regional endpoint choices for SiliconFlow.
  • Improved support for optional-key providers and free provider configurations.

• Bug Fixes

  • Excluded reference-only and directory-only providers from connection and initialization lists.
  • Preserved missing provider configuration details when registry information is available.

[lidge-jun]

Reviewed — two blocking findings:

1. High — directory-only IDs collide with existing custom providers. registry.ts:1045-1049 adds 68 directory-only IDs to the global registry, and derive.ts:210-246 enriches any runtime config whose name matches. A user's custom provider named vertex, baidu, cloudflare-ai, or qoder gets injected models, liveModels:false, and googleMode. Reproduced: qoder loses live discovery; vertex gets unrelated Gemini models + googleMode:"vertex". Directory-only rows must be excluded from runtime enrichment, with a collision regression test.

2. High — incomplete directory exposed in the credential UI. derive.ts:203-207 includes accessGroups entries as GUI presets, but provider-presets.ts:13-60 doesn't understand accessGroups/supportLevel/verification — 66 of 68 directory-only rows land in the Paid tab, and 21 reference-only rows (with unverified/primary endpoints) are selectable and lead to the API-key input in AddProviderModal.tsx:507-509. The baseUrl/authKind in free-directory.ts:51-125 determine where a user's API key is sent — this is a credential-destination trust boundary that needs human security review.

Also missing: directory invariants test, reference-row exclusion test, GUI free-classification test, custom-name collision test, and docs sync for the user-facing change.

Happy to re-review after the enrichment exclusion + UI gating are in.

[HaydernCenterpoint]

@lidge-jun got it boss, will fix it when i wake up!

[lidge-jun]

🔒 Under maintainer review — detailed feedback incoming

@lidge-jun (maintainer) has this PR in an active review pass. Please do not merge or close
it until the detailed review lands; a full comment with specific file:line findings,
failure modes, and suggested fixes is being prepared.

This PR is not part of the current integration batch. It is held back deliberately —
either because it touches a security boundary that MAINTAINERS.md requires an explicit
security review for, because it needs to be split into reviewable units, or because it needs
a rebase onto changes landing in dev right now.

Heads-up on rebasing: dev is receiving a coordinated integration batch today. If this PR
touches the same files, expect to rebase after that batch lands. The upcoming review comment
will name the exact overlapping paths so you only have to do it once.

No action needed from you until then. Thanks for the contribution and for your patience.

_{Review tracker: devlog/_plan/260725_pr_issue_rework · marker posted by the maintainer review pass}

[lidge-jun]

Thank you for assembling the canonical free-provider directory. This PR should not merge independently in its current form.

At src/providers/derive.ts:202, entries marked reference / directoryOnly are still emitted into dashboard presets. The UI guard that prevents those informational rows from being connected (isPresetActionable) exists only in #434, not in this PR. Merging #405 alone would therefore present unverified/reference endpoints as connectable providers, which turns directory metadata into a product trust decision without the corresponding safety gate.

Please either add the actionable-state contract and tests in the same narrowly scoped PR, or keep directory-only rows out of dashboard presets. A regression should prove a directoryOnly entry can be displayed as reference information but cannot create provider config.

#434 already contains #405's four changed file blobs unchanged, so maintaining both also creates duplicate/superseded review work. Please close this PR in favor of the appropriately split directory slice from #434, rebased on current dev. Thanks for the research and curation; it needs to land with the non-actionable boundary intact.

Please also rebase the directory slice onto current dev, which now includes #385's BizRouter registry entry and the expanded registry-parity assertions.

---

_{Reviewed as part of a maintainer integration pass. dev moved to ebc62d1f today (7 PRs integrated); Cross-platform CI is green on ubuntu, macOS, and Windows.}

[lidge-jun]

Integrated the catalog into dev as be16c1d8 with your authorship preserved via Co-authored-by. Closing this PR, though I took the module and left the wiring behind — let me explain why, because your directoryOnly design was a genuine attempt to solve exactly the problem I'm about to describe.

The marker doesn't isolate anything. routedProviderConfig() looks up by id at src/router.ts:121 with no directoryOnly guard, so a directory row in PROVIDER_REGISTRY still canonicalizes a user's same-named provider. Concretely: a user with their own qoder provider pointed at https://custom.example.test/v1 gets routed onto the directory row's baseUrl, which is the empty string — the request loses its destination entirely. vertex and baidu collide differently, replacing the user's adapter and endpoint with Google's and Qianfan's.

Review also found the flag is honored in only two of the projections that need it. Unguarded: runtime routing and known-model merging, CLI provider list and create, deriveProviderPresets(), catalog enrichment and live discovery, subagent provider-prefix classification, and the generic getProviderRegistryEntry() consumers. The GUI DTO carries no supportLevel/verification/directoryOnly at all, so reference rows land in a provider-creation surface that implies they're connectable — they fail only because the URL field starts blank, and a user can just type one in.

So the catalog landed as a standalone module with no runtime consumer. The data is preserved and available; nothing routes through it. When someone builds the UI slice, it should read through its own DTO with a server-side actionable check, rather than teaching every registry consumer about a flag — one missed consumer is the whole hazard, and this head had several.

Two data corrections on the way in. The module stamped a single LAST_VERIFIED = "2026-07-23" on all 81 rows, including the 22 marked verification: "unverified" — a provenance claim nobody actually made. lastVerified is now optional and present only on rows whose endpoint was checked; verified rows must also carry a documentation, models, or dashboard URL. bytez keeps its endpoint but drops the date, since its recurring-credit terms couldn't be confirmed independently.

Both iFlytek rows cited xfyun.cn/doc/spark/Web.html — the WebSocket protocol page — as documentation for https://spark-api-open.xf-yun.com/v1, which is an OpenAI-compatible HTTP endpoint. Repointed at the HTTP guide.

Worth noting the rest of the catalog held up well under spot checks: Baidu Qianfan, Cloudflare Workers AI, OVHcloud, and Nebius all matched their official documentation, and live unauthenticated probes to Bytez, AgentRouter, and LongCat returned provider auth errors rather than dead hosts. One caveat for later — Pollinations' keyless contract wasn't fully verified, so keyOptional: true on that row deserves a focused check before anything acts on it.

Tests lock the isolation rather than the catalog contents: reference ids stay out of PROVIDER_REGISTRY, a custom qoder provider keeps its own destination through routeModel, and unverified rows carry no verification date. I verified these go red by reproducing your append design, so if someone reintroduces it the suite says so immediately.

Thank you for assembling this — 81 endpoints with access-group classification is real research, and it's now in the tree where a UI can pick it up safely.

---

_{Integrated as part of a maintainer PABCD pass. Plan unit: devlog/_plan/260726_pr_close_rework/080_wp8_free_provider_directory_405.md.}