test(inference): add gRPC provider-create-path coverage for built-in profiles

[!IMPORTANT]
Corrections verified against main @ 83284129 — see this comment.
The entrypoint named in the Scope section below (ProviderService::create_provider) does not exist; the real functions are create_provider_record{,_with_catalog}.
Scope item 2 is also blocked on a visibility change: create_provider_record (pub(super) in crate::grpc) and upsert_inference_route (private in crate::inference) are not visible to any common module.

Context

Follow-up to PR #1704 (merged), per @johntmyers's request.

The new route-resolution tests added in PR #1704 (upsert_cluster_route_* in crates/openshell-server/src/inference.rs) insert Provider records directly via store.put_message. That covers the routing logic but bypasses the public CLI path operators actually use:

openshell provider create --type aws-bedrock --credential ... --config BEDROCK_BASE_URL=...

If a built-in profile (aws-bedrock, deepinfra, nvidia, openai, anthropic, google-vertex-ai) drifts from what the gRPC provider create handler accepts — required vs. optional credential validation, discovery behaviour, defaulting — the existing tests won't catch it.

Scope

Add coverage that goes through openshell_server::grpc::provider::ProviderService::create_provider (or the equivalent public entrypoint) for each built-in profile:

1. Positive create path: the documented provider create --type <profile> ... command shape produces a stored Provider record matching what resolve_provider_route expects.
2. Cluster route end-to-end: chain create_provider → upsert_cluster_inference_route (with verify: false for protocols not yet supported by the validation probe — currently aws_bedrock_invoke, but this list is short).
3. Negative paths: for each profile, the gRPC create_provider rejects malformed inputs (empty credential map where required, unknown profile type, etc.) with the same error shape the CLI surfaces.

Why this matters

Documentation in docs/sandboxes/manage-providers.mdx and docs/sandboxes/inference-routing.mdx shows specific provider create commands. Today nothing pins those down to behaviour. A test layer one level up from the route-resolution unit tests would catch docs/profile drift before users do.

Related

• PR #1704 — initial Bedrock plumbing; added the route-resolution tests this issue would complement.

Start with crates/openshell-server/src/inference.rs and the gRPC provider module, then compare the provider-create commands in docs/sandboxes/manage-providers.mdx and docs/sandboxes/inference-routing.mdx with the route-resolution tests from PR #1704. Trace the actual create_provider_record{,_with_catalog} entrypoints and the visibility constraints. Done means coverage for all six built-in profiles, positive and negative creation paths, and the cluster-route chain with the stated verification exception.