Document local adapter footguns in k8s-hosted registry flows

[timflannagan]

When the registry server runs in Kubernetes (Kind/Helm) and users access it via
port-forward or LoadBalancer, arctl deploy create without --provider-id
can resolve to the local provider path. That attempts Docker Compose execution
from the server context and fails with opaque 500s.

This is a footgun because the user is clearly targeting a k8s-hosted registry,
but the default deploy behavior can still route to local runtime logic.

This will result in the following error message in most cases:

Error: failed to deploy agent: unexpected status: 500 Internal Server Error, {"title":"Internal Server Error","status":500,"detail":"Failed to deploy resource","errors":[{"message":"failed to start docker compose: exit status 125: unknown shorthand flag: 'd' in -d\n\nUsage:  docker [OPTIONS] COMMAND [ARG...]\n\nRun 'docker --help' for more information"}]}

Alternatively, we spend cycles investigating ways to refactor the local adapter to
decouple execution from runtime, introduce a "capabilities"-esq concept to adapter
implementations, etc.