task: Implement Kiro spec bulk-inference-provider-expansion

[matdev83]

Implement the merged, implementation-ready Kiro SDD from #534.

Spec: .kiro/specs/bulk-inference-provider-expansion/

The canonical spec.json on main has requirements/design/tasks approved and ready_for_implementation: true.

Purpose / release role

#534 defines broad inference-provider coverage as work to complete before the Open Core release. This task is the authoritative implementation work order for that SDD.

The implementation is intentionally data-first and must preserve the architecture frozen by the spec:

• first repair the existing kind: provider-profile config-to-registry binding so complete compiled profile semantics reach the existing compatible-family builders;
• then add the sequential embedded provider-catalog batches;
• use external backend connectors only for the managed-cloud, dynamic-address, provider-native, or subscription/OAuth cases explicitly classified that way by the SDD;
• do not introduce a second provider framework, provider-name branches in core, a new feature plane, or frontend×provider Cartesian architecture.

Dependencies / sequencing

• No active hard prerequisite inside OSS Base. The SDD was revalidated against the post-extension-plane provider/profile boundaries and explicitly states that feature-plane consolidation is not the provider integration seam.
• Implement against current main and rerun the SDD's required brownfield characterization before production batches, especially the real provider-profile binding RED test.
• This task is a direct prerequisite of feat(split): OSS / Enterprise split [ENDS OSS Base Milestone] ============================================ #398, the OSS Base terminal split gate, because there is no separate feature-level parent issue for the bulk expansion and the SDD explicitly places this work before the Open Core release.
• Do not create duplicate direct feat(split): OSS / Enterprise split [ENDS OSS Base Milestone] ============================================ #398 blockers for the individual provider tickets covered by this bulk plan. Those provider-specific tickets remain useful acceptance/history trackers and should close only when their corresponding implementation actually lands.
• Merged spec: align downstream cache affinity with lean core architecture #569 / post-split task task: Implement Kiro spec downstream-cache-affinity-hinting #573 independently discovered the same lossy provider-profile lifecycle problem. Whichever implementation lands the authoritative ProviderProfileKind lifecycle repair first owns it; the other workstream must verify/reuse that implementation rather than create a second bridge. This is coordination only — do not create a cross-milestone dependency between task: Implement Kiro spec bulk-inference-provider-expansion #545 and task: Implement Kiro spec downstream-cache-affinity-hinting #573/task: Implement Kiro spec core-feature-ownership-full-closure #572.
• The pre-OSS core-slimming production/package-ownership changes are now landed through fix(feature): make generated plane policy canonical #591. task: Implement Kiro spec pre-oss-core-slimming #571 remains open only for final Kiro/repository closeout and is not a hard blocker of task: Implement Kiro spec bulk-inference-provider-expansion #545. Characterization must use the current post-fix(feature): make generated plane policy canonical #591 provider/profile package owners rather than historical paths.

Existing provider tickets covered by this SDD

At minimum, the merged matrix subsumes the implementation planning for existing post-split tickets including:

• feat(backends): Add Vercel AI Gateway Backend Connector #154 — Vercel AI Gateway;
• feat(backends) Add Oracle OCI Gen AI Backend Connector #155 — Oracle OCI Generative AI;
• feat(backends) Add Microsoft Azure OpenAI Backend Connector #156 — Azure OpenAI / Azure AI Foundry;
• feat(backends) Add xAI backend connector #190 — xAI API-key plus subscription/OAuth access.

Those issues are not completed by the spec-only PR and should not be closed until their requested production coverage lands.

Completion

Close this work order only after the SDD's implementation tasks and release gates are complete on main, including truthful model enumeration/capabilities, profile/connector contract coverage, offline deterministic startup, documentation, and repository/provider certification. Partial provider batches are checkpoints, not completion of this task.