fix(providers): enforce declared static credential placement #4883

User Story

As an OpenShell maintainer, I need the supervisor to enforce provider credentials' declared HTTP placement while preserving existing gateway/supervisor interoperability and documented rewrite policies.

Description

Static injection currently substitutes placeholders where a client places them after checking endpoint authorization. Unlike dynamic token-grant injection, it does not enforce the profile's auth_style fields. Forward static auth metadata with the existing provider environment and enforce it locally before substitution.

Use the existing credential metadata map; introduce no new RPC, protobuf field, capability gate, or configuration flag. Metadata describes only actually delivered static credentials and matches their owning provider. New supervisors validate and extract these entries before token-grant processing. Older supervisors ignore entries without token grants; older gateways omit the entries, preserving legacy behavior.

Preserve existing identities, stable handles, endpoint/expiry authorization, trusted signing, and explicit body/WebSocket rewrite policies.

Suggested UX

Existing metadata activates enforcement automatically with supporting components:

credentials:
  - name: api_key
    env_vars: [API_KEY]
    auth_style: bearer
    header_name: authorization

Normal Authorization requests continue working. Moving that credential to an undeclared query parameter or header is rejected before substitution. Credentials without usable metadata retain earlier endpoint-scoped behavior, including Codex refresh/ID tokens and policy-only AWS signers.

Definition of Done

• Supervisor infers and enforces placement from existing static auth metadata.
• Older components and profiles without metadata retain legacy delivery.
• Existing protobuf shapes, RPCs, identities, and stable handles remain unchanged.
• Metadata is bound to delivered material and atomically separated from real token grants.
• Authentication formats, endpoint/expiry boundaries, signing, and explicit body/WebSocket policies have regression coverage.
• Documentation explains automatic enforcement and compatibility limits.
• Relevant local verification passes.