Clean up client authentication story

Right now I think most clients are falling into the port-forwarding / token minting path [1]

This is convenient for local development, but I don't think it should be the default authentication mode. We shouldn't assume that a user or service who is interacting with the Substrate API has any particular permissions on the Kubernetes cluster where Substrate is installed.

1) We should migrate all integration / e2e tests so that the calling code gets a JWT (or client certificate) that will work against the Substrate API from the execution environment. This could be a Kubernetes JWT with the correct audience for connecting to Substrate (via projected volume) if the calling code runs inside a pod. Or if the calling code is running inside of Github actions, there's a Github-issued JWT we can use.

2) We should document what you should be doing in common scenarios:

a) You are authenticating to the Substrate API from a service running inside a pod in a Kubernetes cluster (same cluster or different cluster). Configure Substrate so that it trusts JWTs issued by that cluster.
b) You are authenticating to the Substrate API as a human running `kubectl ate`. Set the `--endpoint` flag to aim at your Substrate install, and tell us how to invoke a command that will return a JWT (like how gcloud is integrated into kubectl) (this isn't built yet)

[1] https://github.com/agent-substrate/substrate/blob/1ec75f9578fe0589a2eb34ae34ae8df46482bf9c/internal/ateclient/builder.go#L241