[Bug]: 0.18.46 provider env namespacing breaks Bedrock region and Azure resource name

Summary

In OpenWork 0.18.46, organisation-managed catalog providers for Amazon Bedrock and Azure fail before inference because required non-secret SDK settings are delivered only under provider-scoped environment-variable names.

The settings are saved in Den and present in the running Desktop App's OpenCode process, but the SDKs still look for AWS_REGION / AZURE_RESOURCE_NAME. The generated provider configuration does not bind the scoped values into options.region / options.resourceName.

This appears to be a regression introduced by the catalog-provider env namespacing in #4281, rather than missing credentials or the older Azure credential-selection bug (#4096).

To Reproduce

1. Use Den API/Web 0.18.46 and Desktop App 0.18.46 on Linux.
2. Configure an organisation-managed catalog Amazon Bedrock provider with a valid AWS_BEARER_TOKEN_BEDROCK, AWS_REGION, selected models and a grant to the member. This is bearer-token authentication, not IAM access-key/SigV4 authentication.
3. Alternatively, configure an organisation-managed catalog Azure provider with AZURE_API_KEY, AZURE_RESOURCE_NAME, selected models and a grant to the member.
4. Sign in with the Desktop App and allow managed-provider configuration to sync. Fully quit/relaunch so old unprefixed process environment values cannot mask the issue.
5. Select an assigned Bedrock or Azure model and send a simple prompt.

Observed with Claude Sonnet 5 on Bedrock and an Azure OpenAI deployment. Both fail at SDK configuration, before a provider response.

Expected behavior

Managed catalog providers should work using the saved settings, while retaining provider-row isolation. Members should not need to export global AWS/Azure variables manually.

Actual behavior

Bedrock:

AWS region setting is missing. Pass it using the 'region' parameter or the AWS_REGION environment variable.

Azure:

Azure OpenAI resource name setting is missing. Pass it using the 'resourceName' parameter or the AZURE_RESOURCE_NAME environment variable.

OW version & Desktop info

• Desktop App: Linux x86_64 AppImage, 0.18.46.
• Bundled OpenCode: 1.18.18, verified from the running AppImage's resources/sidecars/versions.json.
• Den API and Den Web: official 0.18.46 images, verified from running Kubernetes pods.
• Bundled SDKs inspected: @ai-sdk/azure 3.0.88 and @ai-sdk/amazon-bedrock 4.0.112.
• These managed providers had previously passed real inference checks on 0.18.37. The first failing version has not been bisected.

Verified runtime evidence

Inspected the actual running Desktop App engine's /proc/<pid>/environ, the persisted env store, generated runtime provider configuration, and read-only Den database metadata. No credential values are included here. Provider tags below are illustrative replacements for the real IDs.

The generated runtime-opencode-config.json contains managed lpr_... provider entries using @ai-sdk/amazon-bedrock and @ai-sdk/azure, with the scoped env lists, but neither provider has any SDK options. Azure also has no explicit base URL in the inspected provider configuration.

The database retains the unprefixed declared env names and encrypted credentials. Our previous credential-first env ordering is still intact and the rows have not changed since August 27. Reordering the env array again would not address the missing auxiliary settings.

The dashboard correctly marks the Bedrock region and bearer token as saved. Blank access-key/secret-key fields are expected for this bearer-token setup; they are not the cause of this failure.

Suspected cause and repair direction

In the 0.18.46 source:

• toRuntimeProviderEnv, introduced by #4281, scopes every catalog env name, including auxiliary settings. It rewrites providerConfig.env and the apiKeys map, but does not create SDK option bindings.
• Desktop provider materialization preserves those scoped names and passes existing options through unchanged.
• Managed auth delivery supplies an API credential, not the region/resource-name settings.

The shipped SDKs accept explicit region / resourceName options; without those, they fall back to the original global variable names. Bedrock's SDK supports the bearer token via apiKey, so restoring global AWS credential variables should not be necessary.

Please preserve namespacing and bind the scoped auxiliary settings into provider-specific SDK options during runtime configuration generation, covering Desktop and worker paths. Azure configurations with explicit templated API/base URLs also need their variable references resolved consistently; resourceName alone does not repair an already-supplied unresolved URL.

A database options patch may be a temporary workaround, but normal catalog-provider saves reconstruct the configuration, so it is not a durable fix. No workaround or database mutation was applied during this diagnosis.

Suggested regression coverage: use only scoped env variables, no ambient AWS/Azure fallback, and exercise actual SDK request construction for both Azure and Bedrock bearer auth. Confirm sync and a full restart retain working configuration and do not expose the built-in unrestricted catalog. Successful inference/authentication after a fix has not yet been verified.