Add built-in Posit Connect provider

[ssinnott]

Make Posit Connect a built-in provider: one provider fronts every OAuth integration on a Connect server, folding their models into a single namespaced list instead of runtime-injected custom-provider entries.

• Anthropic integrations discover their models live through the gateway; the Bedrock gateway can't list models, so those come from a declared table in ai-config.
• Bedrock chats mint short-lived AWS credentials per request through a host callback; the bridge never stores them.
• The server URL comes from providers.json or POSIT_CONNECT_URL; without one the provider lists no models.
• BedrockClient now honors a per-request base URL, letting chats target the Connect gateway.
• The real change is connect-provider.ts; the regenerated JSON schema and lockfile are churn.

Testing

New tests cover integration shaping (template allowlist, Viewer-auth filtering, prefix minting with collisions), raw discovery requests against both gateways, per-integration failure isolation, chat dispatch on both protocols including credential-mint failures, and the capability table's delegation and fallback. Bedrock's base-URL honoring gets its own routing tests.

Commits

• 0d02975 - Honor baseUrl on Bedrock's Anthropic and Converse routes
• df92ae1 - Add built-in Posit Connect provider

🤖 Generated with Claude Code

[wch]

I have some questions about endpoints:

• How does it handle, say, OpenAI as a provider? Does it use the Responses protocol there?
• Similarly, for Bedrock, there is a relatively new Mantle endpoint which is used for the OpenAI models. Is this supported?
• I asked PA about the code, and it says that if Posit Assistant were to use Anthropic models via Bedrock via this Connect provider, it would use the Bedrock Converse protocol. But we would want to use the Anthropic Messages protocol, because there are some features (like cache markers) that may get lost in translation.
• Bedrock has an endpoint for listing models. We use it for the regular Bedrock provider. Why not use it here?
• How are other providers handled?

In general, it's best to speak a model's native protocol whenever possible.

Some feedback from running the /assistant-review skill from the Assistant repository, where packages/ai-lib is a submodule (using gpt 5.6 sol high):

• critical (security) - packages/ai-provider-bridge/src/providers/connect-provider.ts:395: Connect's integrations endpoint is scoped to the calling user, but createCachedModelFetcher caches one model list per registered provider, independent of credentials, and the adjacent integration map is shared the same way. After token A populates the cache, token B on the same registry receives A's integration names, GUID-backed routes, and models for up to an hour without making its own discovery request; scope both caches by credential identity and Connect URL, or avoid the shared provider cache for this user-specific catalog, and add a two-token regression test.

• critical (compliance) - packages/ai-provider-bridge/src/model-clients/BedrockClient.ts:259: when AWS FIPS mode is enabled, an explicit baseUrl now wins over the resolved FIPS runtime endpoint and the request proceeds after only a warning. This breaks the existing fail-closed transport policy (Mantle is rejected under FIPS for the same reason) and lets both Connect and ordinary Bedrock model overrides send traffic to an endpoint with no FIPS guarantee; reject the override unless a separate explicit policy can attest that the custom endpoint is permitted.

• important (correctness) - packages/ai-provider-bridge/src/providers/connect-provider.ts:165: model identity is derived from mutable display text and one-pass collision order. Reversing two same-name integration records transfers the unsuffixed connect-<slug> ID to the other GUID, so a persisted (providerId, modelId) selection can silently route to a different integration after refresh; use the immutable full GUID as the namespace and keep the human name only in ModelInfo.name.

• important (correctness) - packages/ai-provider-bridge/src/providers/connect-provider.ts:514: the documented cache fallback for user-configured, unstamped models is unreachable through the normal catalog pipeline. resolveModels assigns the provider-wide Connect root URL as resolvedBaseUrl, so chat enters this params.baseUrl branch and rejects that root as "not a Connect gateway URL" instead of consulting byPrefix; treat the configured root as unstamped (or store it outside the generic chat-endpoint field) and cover the path through resolveModels, not only a direct client call with baseUrl omitted.

• important (correctness) - packages/ai-provider-bridge/src/model-clients/BedrockClient.ts:247: customHeaders is passed raw to all three Bedrock SDK factories, violating ApiKeyCredentials' contract that SDK-managed names such as Authorization, x-api-key, and Content-Type are ignored. Every other direct SDK client filters through safeSdkCustomHeaders; do the same once here and add a reserved-header assertion so custom Connect metadata cannot interfere with SigV4 or provider headers.

[ssinnott]

Ok chatted with the connect team. The this feature is preview. So the support is a little limited right now.

1. Only anthropic and bedrock support today.
2. There's no mantle support today - and bedrock only supports some of the urls today.