fix: [ENG-2897] route all OpenAI-compatible providers to 'openai' registry type (#701)

* fix: [ENG-2897] route all OpenAI-compatible providers to 'openai' registry type

resolveRegistryProvider only listed 6 of the 17 user-facing provider IDs
that talk OpenAI-compatible APIs. The other 11 (deepseek, glm,
glm-coding-plan, moonshot, cerebras, cohere, deepinfra, togetherai,
vercel, minimax, perplexity) fell through to the 'gemini' default,
breaking acceptsAnyModel bypass, context-length lookups, and tokenizer
selection — surfaced by openai-compatible users in #691 but latent for
the other ten.

Cross-checks the resolver's hardcoded list against PROVIDER_MODULES so
any future OpenAI-compatible provider added in infra fails the test
unless the resolver is updated in sync.

* fix: [ENG-2897] address PR #701 review — explicit byterover mapping + all-bucket cross-check

Reviewer flagged that `byterover` (declared providerType: 'gemini')
resolved correctly only via the terminal `return 'gemini'` fallback —
by accident, not by design. A future refactor of the default branch
would silently regress it on the same path that bit openai-compatible.

- Map `byterover` explicitly in the gemini branch alongside `google` /
  `google-vertex`, so resolution is intent-driven rather than fallback-
  driven.
- Generalise the regression test to iterate every provider module and
  assert it resolves to its declared `providerType`. Now covers all
  three buckets (claude / gemini / openai = 24 cases vs 22 before),
  so drift on the claude/gemini side fails loudly instead of slipping
  through the same gap.
- Pin `google-vertex` separately (no infra module, only in
  PROVIDER_REGISTRY) so it stays covered by an explicit test.
- Tighten the registry comment: "at build time" -> "at test time" to
  match the actual mocha-runtime check.

---------

Co-authored-by: bao-byterover <bao@byterover.dev>