feat(providers): make profiles authoritative

[johntmyers]

Summary

Make provider profiles authoritative for new provider creation and discovery, removing the Providers v2 compatibility switch and legacy public provider workflows.

Related Issue

Closes #1988

Changes

• removes providers_v2_enabled and always composes attached profile policy for sandbox-scoped policies
• requires built-in or imported profiles for new providers while preserving existing legacy records
• adds built-in openai and anthropic profiles and retires public generic, gitlab, opencode, and outlook selection/discovery
• supports credentialless policy-only and runtime-resolvable profiles without dummy credentials
• moves CLI and TUI creation/discovery to profile metadata
• updates examples, e2e fixtures, docs, architecture notes, and agent skills
• preserves custom imported profiles, including deployment-specific GitLab profiles
• fixes S3 signing-region inference exposed by unconditional profile composition

Testing

• mise run ci
• mise run test
• mise run e2e:rust
• mise run e2e:python (89 passed, 84 skipped)
• mise run docs:build:strict
• cargo test --manifest-path e2e/rust/Cargo.toml --all-features --no-run
• cargo test --manifest-path examples/governance-interceptor/Cargo.toml

Checklist

• Tests added or updated
• Documentation updated
• Generated bindings updated
• Agent workflow documentation reviewed
• DCO sign-off included

[github-actions]

🌿 Preview your docs: https://nvidia-preview-pr-2962.docs.buildwithfern.com/openshell

[johntmyers]

gator-agent

PR Review Status

The current head is a patch-identical rebase of the already-reviewed change, so no additional code review is needed and no blocking Gator findings remain. The required current-head E2E workflow is queued and running, so pipeline monitoring can resume.

Blocking findings:

• No code-review blockers remain

Carried findings:

• None; the feedback ledger reports no open Gator threads

Gator metadata

• Validation: project-valid maintainer-authored implementation of linked issue feat(providers): make Providers v2 the only provider system #1988
• Docs: Fern provider docs and navigation cover the direct UX changes
• Checks: current-head Branch Checks, Helm Lint, DCO, docs preview, and published non-E2E required gates are green; OpenShell / E2E is pending
• E2E: test:e2e is present and current-head Branch E2E Checks run 33453212430 is queued/running; no /ok to test or rerun is currently required
• Head SHA: 60598bc35316e7e28b301d91dc43e44510fe6cf7
• Base SHA: 5c541e1e0e0cfed3a631ee438916cbc71e7b1c6b
• Merge base SHA: 5c541e1e0e0cfed3a631ee438916cbc71e7b1c6b
• Patch ID: 263202a8aa5e38aab8bbfe8736a485d894ee8133
• Gator payload: 7
• Review mode: already_reviewed
• Previous reviewed SHA: a096026bb7525845aabf3ac0311cd78134d396c5
• Review budget exhausted: yes
• Maintainer decision required: no; the effective patch is unchanged and no durable review obligation remains
• Review telemetry: 6 finding-bearing rounds, 12 unique historical findings, 195 duplicate finding-ID occurrences; current patch matches the last review
• Next state: gator:watch-pipeline

[drew]

Global-profile updates resolve against a workspace shadow

Before this PR, provider updates retained the provider scope already selected by the stored record. With authoritative profiles, a provider created with --global-profile persists profile_workspace == "", which the server interprets as platform scope. In provider_update, the OIDC branch replaces that empty scope with the current workspace, and the --from-existing branch always passes workspace instead of the persisted existing.profile_workspace. When the workspace shadows the same profile ID, discovery or OIDC subject-token inference uses the workspace profile while the gateway validates and runs the provider against the platform profile. A valid global-provider update can therefore fail with misleading credential errors or select credentials from the wrong profile.

Please resolve both update paths using the persisted profile scope and add a regression with same-ID platform and workspace profiles.

[drew]

Profile deletion can orphan newly created providers

Before this PR, profileless providers were a supported model. This PR makes profiles authoritative for every new provider record, but handle_delete_provider_profile checks only sandboxes that currently attach the profile. An administrator can create a provider from a custom profile, delete that profile while the provider is unattached, and then attach the orphaned provider: attachment validates that the provider record exists, but the missing profile contributes no provider-owned policy or endpoint binding. That recreates a new profileless provider through supported operations and bypasses the authoritative-profile invariant.

Please reject deletion while any provider record in the applicable scope references the profile, and synchronize create versus delete so the check cannot race; alternatively, reject later attachment while preserving compatibility only for genuine pre-migration records. Add a create, delete-profile, then attach regression.