feat(providers): add Docker Agent provider

[ericcurtin]

Summary

• Add `docker-agent` as a built-in agent provider for OpenShell
• Enables `docker agent` to be sandboxed and policy-enforced within OpenShell
• Covers Docker Hub OCI registry endpoints (including `auth.docker.io` for token auth), the Docker Model Runner internal endpoint, and an optional Hub access token for private repositories
• Provider is discoverable without credentials whenever a docker binary is present (token is optional for public images and local Model Runner)

Related Issue

N/A — new provider addition from the Docker ecosystem.

Changes

• providers/docker-agent.yaml — declarative profile: agent category, Docker Hub + auth.docker.io + model-runner endpoints, optional DOCKER_ACCESS_TOKEN credential
• crates/openshell-providers/src/providers/docker_agent.rs — DockerAgentProvider plugin with binary-presence discovery; uses path_exists() on DiscoveryContext so the provider is found even without a token
• crates/openshell-providers/src/context.rs — add path_exists() default method to DiscoveryContext trait
• crates/openshell-providers/src/test_helpers.rs — add with_path() to MockDiscoveryContext for unit-testable binary checks
• crates/openshell-providers/src/lib.rs — register plugin; add docker-agent/docker_agent aliases; special-case ["docker", "agent", ...] in detect_provider_from_command so sandbox auto-inference maps the sub-command invocation correctly
• crates/openshell-providers/src/providers/mod.rs — expose docker_agent module
• crates/openshell-providers/src/profiles.rs — embed YAML at compile time

Testing

• All existing openshell-providers unit tests pass
• New unit tests in docker_agent.rs: token discovery, tokenless binary-present discovery, no-discovery without token or binary
• Regression test for detect_provider_from_command with ["docker", "agent", ...]
• cargo clippy -p openshell-providers — clean

Checklist

• Follows Conventional Commits format
• SPDX license headers present on all new files
• No credentials or secrets introduced
• Unit tests added for new provider plugin
• Profile YAML validates (covered by default_profiles_are_sorted_by_id test)

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[johntmyers]

Code-only review findings:

• [P2] providers/docker-agent.yaml:13 marks DOCKER_ACCESS_TOKEN optional, but crates/openshell-providers/src/providers/docker_agent.rs:12 only discovers that env var and provider creation rejects empty credentials. Public Docker Hub / local Model Runner users without a token cannot create or auto-create this provider, so no provider policy gets attached.

• [P2] crates/openshell-providers/src/lib.rs:150 normalizes docker-agent, but detect_provider_from_command() only checks the first token. A real invocation is docker agent ..., so sandbox auto-provider inference sees docker and returns None. Please add a ["docker", "agent", ...] special case and regression test.

• [P2] providers/docker-agent.yaml:16 omits auth.docker.io:443. Docker Hub registry pulls commonly require the token service advertised by the registry auth challenge, so the policy can deny pulls even when registry access is allowed. Docker documents the Docker Hub token realm at auth.docker.io/token: https://docs.docker.com/reference/api/registry/auth/

Open question: is DOCKER_ACCESS_TOKEN definitely consumed by docker agent, or should discovery also cover Docker's existing config/credential-store path?

Testing not run; this was code-only.

[ericcurtin]

Added auth.docker.io:443 endpoint so Docker Hub token-service requests aren't blocked during registry pulls.

Added a special case before the basename lookup: if command[0] basename is docker and command[1] is agent, it returns "docker-agent".

DOCKER_ACCESS_TOKEN optional but discovery rejected empty credentials.