Support Docker HTTPS/TLS contexts via context metadata

[agustif]

Summary

Coasts now has a path to resolve local Docker context sockets, but it still does not support Docker contexts whose endpoint is tcp:// / https:// and whose TLS material is stored in Docker's context metadata storage.

This affects remote/TLS Docker contexts even when they are the active Docker context and work with the Docker CLI.

Desired behavior

When Coasts resolves a Docker context endpoint:

• unix:// or npipe:// should keep using the local socket path
• tcp:// / http:// without TLS material should use HTTP
• tcp:// / https:// with TLS material should use TLS
• ssh:// is explicitly out of scope for this issue

References

• Docker CLI env vars: https://docs.docker.com/reference/cli/docker/
• Docker contexts: https://docs.docker.com/engine/manage-resources/contexts/
• docker context inspect: https://docs.docker.com/reference/cli/docker/context/inspect/

The docker context inspect output includes:

• Endpoints.docker.Host
• Storage.TLSPath

Those should be enough to locate ca.pem, cert.pem, and key.pem for context-driven TLS connections.

Proposed implementation split

1. Extend coast-docker::host only.
2. Keep explicit env-driven DOCKER_HOST / DOCKER_TLS_VERIFY / DOCKER_CERT_PATH behavior delegated to Bollard's existing env-aware connection path.
3. Add resolver tests for:
   • TLS context metadata with Storage.TLSPath
   • plain HTTP/TCP context without TLS material
   • unsupported ssh:// context

Implemented on #64