Native AWS Bedrock provider (Claude/GPT) with AWS profile support

### Feature summary

Native AWS Bedrock support as a model provider (Claude, GPT-OSS, etc.), with the ability to specify an AWS profile for credentials.

### What problem are you trying to solve?

The current custom/BYOK provider integration assumes an **OpenAI-compatible HTTP endpoint authenticated with a static API key** (the same shape used for Microsoft Foundry, OpenCode, Ollama, etc.). AWS Bedrock doesn't fit that model in two ways:

1. **Auth** — Bedrock authenticates with **AWS SigV4 / IAM credentials** (access key + secret, session tokens, assume-role), not a single bearer/API key. Many AWS shops disable long-lived keys entirely and rely on profiles/SSO.
2. **Protocol** — Bedrock speaks its native **`Converse` / `InvokeModel`** API, not OpenAI `/chat/completions`. The request/response and streaming shapes differ, so pointing the existing custom-endpoint client at a Bedrock endpoint doesn't work.

Today the only way to use Bedrock models is to stand up a translation proxy (e.g. LiteLLM or the Bedrock Access Gateway) that exposes an OpenAI-compatible endpoint and handles SigV4 + Converse on the backend. That's extra infrastructure to deploy, secure, and maintain — a real barrier for teams that are already standardized on Bedrock.

### Proposed solution

Add a first-class **AWS Bedrock provider** that:

- **Resolves credentials via the standard AWS credential chain**, and crucially lets the user **specify an AWS profile** (e.g. a `profile` field that maps to a named profile in `~/.aws/credentials` / `~/.aws/config`). This naturally supports SSO and assume-role profiles, which is how most orgs manage Bedrock access without static keys.
- Lets the user pick a **region** and select from available Bedrock model IDs (e.g. `anthropic.claude-*`, `openai.gpt-oss-*`).
- Speaks the native Bedrock **`Converse` / `ConverseStream`** API under the hood so no external gateway/proxy is required.
- Optionally supports **Bedrock API keys** (the bearer-token style AWS introduced in 2025) for the simpler single-credential case, in addition to profile-based auth.

A minimal first step would be profile + region selection wired to `Converse`/`ConverseStream`.

### Workflow impact

Helps any team standardized on AWS Bedrock — common in enterprises with data-residency, compliance, or existing AWS billing/governance requirements. It removes the need to run and maintain a translation proxy, and respecting AWS profiles means it works with SSO/assume-role setups where static API keys are disallowed by policy.

### Installation context

Local desktop install, used by developers who already have AWS credentials/profiles configured on their machine.

### Additional context

- AWS Bedrock now hosts **both OpenAI and Anthropic models** as first-class options, which makes native support especially valuable:
- OpenAI models on Bedrock: https://aws.amazon.com/bedrock/openai/
- Anthropic (Claude) models on Bedrock: https://aws.amazon.com/bedrock/anthropic/
- This is **not** covered by the existing BYOK/custom-endpoint feature, which is API-key + OpenAI-compatible only (see #1299 asking for RBAC instead of API-key-only auth for similar reasons).
- Current workarounds: [LiteLLM](https://github.com/BerriAI/litellm) or the [Bedrock Access Gateway](https://github.com/aws-samples/bedrock-access-gateway), both of which proxy Bedrock behind an OpenAI-compatible endpoint.
- AWS Bedrock `Converse` API: https://docs.aws.amazon.com/bedrock/latest/userguide/conversation-inference.html

Start by comparing the existing custom/BYOK provider integration with AWS Bedrock’s Converse and ConverseStream API documentation. Define the minimal first step as profile and region selection with native request and streaming support; done means a local desktop install can use configured AWS profiles and a selected Bedrock model without a proxy.

Written by the indexing model from the issue text.