feat: support provider-profile and typed middleware attachment selectors

Problem Statement

network_middlewares currently selects requests only by destination host through endpoints.include and endpoints.exclude. Selection is independent of the network policy entry that admitted the request.

This is limiting when network access comes from provider profiles. A sandbox policy cannot say "apply this middleware to traffic introduced by the github provider profile" without copying the profile's current host set into the middleware selector. That duplication can drift as provider profiles change and loses the semantic reason why the endpoint is present.

The attachment model should support provider profiles and other typed request dimensions, such as inference traffic, while keeping middleware configuration owned by the sandbox policy.

Follow-up to this RFC 0009 review thread. Related foundational middleware work: #1694.

Proposed Design

Replace the host-only attachment concept with an extensible, typed selector model. Provider profile identity should be the first additional dimension. The schema should support multiple selector clauses, with OR semantics between clauses and AND semantics between fields in one clause. For example, a middleware could match any traffic introduced by the github provider profile, or only inference traffic to a constrained host set.

Keep the middleware binding and implementation-specific configuration in the sandbox policy. Do not embed sandbox-specific middleware configuration into provider profiles. Select provider profiles by canonical profile ID rather than provider instance name so the attachment follows the policy capability, not one credential object.

Resolve selectors when the gateway composes the effective sandbox policy:

• Preserve the provenance of network rules contributed by provider profiles instead of deriving attachment behavior from generated _provider_* rule keys.
• Resolve provider-profile and other typed dimensions into a deterministic effective middleware plan before delivery to the supervisor.
• Validate referenced dimensions and provider profile IDs when the policy is created or updated.
• Recompose and revalidate the effective middleware plan when an attached provider or provider profile changes.
• Preserve the current middleware ordering, failure behavior, and run-once semantics after selection.
• Continue rejecting configurations that could require middleware on uninspectable traffic, such as matching tls: skip endpoints.

The exact wire shape can be finalized with the implementation, but it should use a structured selector object that can grow without adding a new one-off top-level field for every dimension. Free-form labels should not become an implicit policy API; supported dimensions and their values should be validated.

Definition of Done

• A sandbox policy can select middleware by provider profile ID without duplicating provider endpoint hosts.
• The selector representation supports adding typed dimensions such as inference traffic.
• Composition preserves enough policy provenance to resolve selectors without depending on _provider_* generated keys.
• Invalid or missing selector references fail at policy authoring/update time with actionable diagnostics.
• Provider attachment and provider-profile updates trigger effective-policy recomposition and middleware revalidation.
• Ordering and deduplication are deterministic when a request matches multiple selector clauses or dimensions.
• Automated tests cover provider-derived endpoints, combined dimensions, overlapping selectors, profile updates, and tls: skip conflicts.
• The policy schema and supervisor middleware documentation describe the new attachment semantics.

Alternatives Considered

Duplicate provider hosts in endpoint selectors

This works with the current schema but creates two sources of truth. Middleware coverage can silently become incomplete when a provider profile adds or changes endpoints.

Put middleware attachments in provider profiles

This keeps the attachment near provider-owned network policy, but couples reusable provider profiles to sandbox-specific middleware bindings and configuration. It also makes per-sandbox variation harder.

Hoist middleware configuration into a separate global entity

This could reduce repetition across sandboxes, but introduces a broader lifecycle, ownership, and configuration-delivery model. It can remain a separate future extension and is not required to support richer attachment selectors.

Agent Investigation

• Reviewed the linked RFC discussion and its follow-up, which explicitly deferred provider-profile attachment and suggested other dimensions such as inference.
• Confirmed the current policy schema exposes only host selectors on network_middlewares, and rejects middleware attachment fields on network policy rules and endpoints.
• Confirmed provider profile network policy is composed into the effective sandbox policy under generated _provider_* keys. The current ProviderPolicyLayer carries the generated rule name and rule, but not stable provider-profile provenance.
• Searched existing issues for middleware provider-profile and selector attachment work. #1694 covers the foundational middleware layer, but no issue was found for this attachment extension.

Checklist

• I've reviewed existing issues and the architecture docs.
• This is a design proposal, not a "please build this" request.

Start with the current network_middlewares schema and the ProviderPolicyLayer described in the issue, then read the linked RFC discussion and foundational middleware work in #1694. Map how provider-derived endpoints and generated provider* rule keys are composed today. Done means the design and implementation meet the listed selector, validation, recomposition, ordering, conflict, testing, and documentation requirements.