RFE: support dynamic credential injection for multiple provider paths on the same hostname

[dhirajsb]

User Story

As an OpenShell user, I want dynamic credential injection to work for multiple provider endpoints sharing a hostname and port but using different paths, so I do not need a separate hostname for each authenticated service.

Problem Statement

The public source has different dynamic credential behavior in the single-endpoint REST relay and the multi-route relay. The latter selects a path-specific endpoint configuration but does not call token_grant_injection::inject_if_needed before forwarding.

Illustrative configuration:

• Provider A: api.example.com:443/service-a, protocol rest, dynamic token grant.
• Provider B: api.example.com:443/service-b, protocol rest, dynamic token grant.

Both endpoints permit POST to their respective paths. Clients rely on supervisor-managed authentication rather than supplying bearer tokens themselves.

Public Source Evidence

In v0.0.116:

• Proxy dispatch: one endpoint configuration uses relay_with_inspection; multiple configurations use relay_with_route_selection.
• Multi-route relay: path selection and forwarding lack a call to dynamic token-grant injection.
• Single REST relay: calls inject_if_needed before forwarding.
• Credential selector: already matches hostname, port, and request path.

The same missing hook is present in source inspected for v0.1.0-pre.1 through v0.1.0-pre.10 and main at a8f98ec09de502bad1edc5b1a903382d27b8be0e.

This report is based on public source inspection. The scenario below is a proposed regression test, not a claim of an independently executed minimal reproducer.

Proposed Reproduction / Regression Test

1. Set up a controlled upstream and a working dynamic token resolver for one REST endpoint. Verify credential injection.
2. Add another endpoint on the same hostname and port with a non-overlapping path and a distinct credential.
3. Send requests to both paths without client-supplied Authorization headers.
4. Assert that the resolver runs and the upstream receives the correct credential for each path. Do not log token values.

Impact

The source-level gap can prevent authentication when multiple services are consolidated behind one hostname. A hostname-per-service workaround introduces DNS, certificate, and routing requirements.

Acceptance Criteria

• Apply dynamic token-grant resolution and header injection in the multi-route relay after policy authorization and before upstream forwarding.
• Match credentials by hostname, port, and request path without cross-provider credential leakage.
• Cover multiple paths on persistent connections.
• Preserve path canonicalization, ambiguity checks, generation invalidation, and fail-closed behavior on resolution failures.
• Add tests for single versus multiple endpoint configurations, grant failures, and credential refresh/expiry.
• Check the related native MCP/JSON-RPC relay path, which also lacks this hook in the inspected source, and either support it or track it separately.