feat(providers): composable provider profiles with explicit credential↔endpoint relationship

Problem Statement

Today, accessing a new AWS service means authoring a full service-specific provider profile that bundles both credentials (STS refresh material) and endpoints. providers/aws-s3.yaml is the concrete example: it carries the STS AssumeRole refresh config and the S3 endpoint allowlist together.

This couples two concerns that naturally vary independently:

• Credentials are shared across an entire suite of AWS services (one AssumeRole session works for S3, Lambda, etc.).
• Endpoints are per-service.

As a result, a user who wants to reach several AWS services must re-declare the same credential/refresh material in each service profile, and every new service needs a new profile that duplicates the credential half.

Proposed Design

Split the two concerns into separate, composable provider profiles that the user attaches together to a sandbox:

• aws.yaml — credentials only (the STS refresh material it already carries).
• aws-<service>.yaml (e.g. aws-s3, aws-lambda) — endpoints only, no credentials.

The user configures the aws credential provider instance once and reuses it with multiple service providers:

• provider_1: brings AWS creds
• provider_2: access S3
• provider_3: access Lambda

The core problem to solve

The credentials↔endpoints relationship becomes implicit. A sandbox attached to aws-s3 but not aws would pass configuration but fail at runtime during SigV4 signing (no credentials available to sign with). That late, opaque failure is the reason this wasn't done in the originating PR.

The design work is making that relationship explicit and validated — so an endpoint-only service provider declares its dependency on a credential-bearing provider, and attach-time validation rejects an incomplete combination instead of letting it fail during signing.

This overlaps with the additional_outputs model introduced in NVIDIA/OpenShell#1782 (a refresh declaring the extra credentials it co-mints), which should inform how the dependency is represented and validated.

Alternatives Considered

• Status quo (bundled profiles): each service profile duplicates credential/refresh material. Simple, but no reuse and N copies of the same STS config to keep in sync.
• Implicit composition (attach both, no validation): achievable today by attaching aws + aws-<service> but the dependency is invisible and only surfaces as a runtime signing failure — poor UX and hard to debug. Making the relationship explicit and validated is the improvement this issue tracks.

Agent Investigation

Originating discussion: review thread on providers/aws-s3.yaml:61 in NVIDIA/OpenShell#1782.

Relevant context from that PR:

• providers/aws-s3.yaml currently bundles STS refresh material + S3 endpoints.
• providers/aws.yaml is a generic base profile with STS refresh material but no endpoints (users attach their own policy for endpoints today).
• The additional_outputs refresh model (a refresh declaring co-minted sibling credentials, with the output→env-key mapping pinned at configure time) was added in #1782 and is the closest existing mechanism for representing multi-credential relationships explicitly.

Related

• Follow-up from NVIDIA/OpenShell#1782 (review thread on providers/aws-s3.yaml)
• Refs NVIDIA/OpenShell#1576
• cc @johntmyers @pimlock

Read providers/aws-s3.yaml and providers/aws.yaml to compare the bundled and credential-only profiles. Then inspect the additional_outputs refresh model introduced in #1782 and trace provider attachment validation. Done means service profiles declare their credential dependency and incomplete combinations are rejected at attach time rather than during SigV4 signing.