feat: add forward_headers support to inference passthrough provider

[skamenan7]

What does this PR do?

Adds per-request HTTP header forwarding to the remote::passthrough inference provider, following the pattern established by the safety passthrough provider (PR #5004, already merged).

A forward_headers config field maps provider-data keys to outbound HTTP header names. Only explicitly listed keys are forwarded from X-LlamaStack-Provider-Data to the downstream service (default-deny). An extra_blocked_headers field lets operators add custom blocked names on top of the core security list.

The shared utility providers/utils/forward_headers.py is used by both the inference and safety passthrough providers, keeping the forwarding logic and blocked-header policy in one place.

Closes #5040
Relates #4607

Test Plan

Unit tests cover the full path — config validation, header extraction, CRLF sanitization, blocked-header enforcement, auth priority chain, and concurrent request isolation:

uv run pytest tests/unit/providers/inference/test_passthrough_forward_headers.py -v

Tests cover:

• build_forwarded_headers() — key mapping, default-deny, CRLF stripping, SecretStr unwrap, case-insensitive dedup
• validate_forward_headers_config() — blocked header rejection, operator extra blocklist, invalid names
• Adapter auth priority — static api_key > passthrough_api_key > forwarded Authorization
• Provider data validator — extra fields preserved for forwarding, reserved keys rejected
• Concurrent request isolation — contextvars don't leak between parallel requests

Also tested end-to-end locally against a mock inference server and a mock /v1/moderations server. Headers land on the downstream exactly as configured and blocked headers are rejected at stack startup, not at request time.

Example config:

providers:
  inference:
    - provider_id: maas-inference
      provider_type: remote::passthrough
      config:
        base_url: ${env.PASSTHROUGH_URL}
        forward_headers:
          maas_api_token: "Authorization"
          tenant_id: "X-Tenant-ID"

Callers pass credentials via X-LlamaStack-Provider-Data:

curl http://localhost:8321/v1/chat/completions \
  -H 'X-LlamaStack-Provider-Data: {"maas_api_token": "Bearer user-jwt", "tenant_id": "acme"}' \
  -d '{"model": "passthrough/my-model", "messages": [{"role": "user", "content": "hello"}]}'

The downstream receives Authorization: Bearer user-jwt and X-Tenant-ID: acme. Only keys explicitly listed in forward_headers are forwarded to the downstream service. Any keys in X-LlamaStack-Provider-Data that don't have a mapping in forward_headers are ignored — they never leave the stack. This is the default-deny policy: if it's not in the config, it doesn't get forwarded.

[skamenan7]

cc: @leseb I have addressed your safety pr #5004 here and refactored to a common utility so this functionality can be easily reused for follow on PRs for other providers as per your suggestion. Thanks!

ps: I can also open another github issue and pr for safety passthrough #5004 if keeping them separate from this PR makes sense.

[cdoern]

looks pretty good. one question

[cdoern]

looks reasonable now, one question

[leseb]

@skamenan7 unit tests are failing

[skamenan7]

• CI Status / ci-status (pull_request)Failing after 7m RequiredMore actions

• #### Unit Tests / unit-tests (3.12) (pull_request)Failing after 1m

@leseb looks like the unit-tests (3.12) failure is a pre-existing flake in test_remote_vllm.py::test_openai_chat_completion_is_async, unrelated to this PR. It's a timing-sensitive test that runs 4 parallel 0.5s coroutines and asserts the total time is <1.0s — on a loaded CI runner it occasionally fails over. The test passes locally consistently and isn't in our diff.