Support self-refreshing custom secrets (exec-credential / --command)

[cholpas]

Problem

We use Google Artifact Registry as our private Maven repository. Authentication
works well with a custom secret:

gcloud auth print-access-token | sbx secret set-custom <NAME> --host <MAVEN_REPO> --env GCLOUD_TOKEN --placeholder gcloud_token

However, GCP access tokens expire after ~60 minutes. Because the proxy substitutes
the stored value at request time, re-running the command above does refresh a
running sandbox without recreation — but it has to be triggered manually or via
external cron/systemd machinery on the host. Long-running agent sessions otherwise
fail mid-work with 401s once the token expires.

This is a follow-up to #7: custom secrets now make non-built-in services usable,
but short-lived credentials (GCP, AWS STS, Azure, OIDC-minted tokens generally)
can't stay fresh without tooling outside sbx.

Proposal

Let a custom secret be backed by a host-side command instead of a static value,
similar to kubectl exec credential plugins and Docker credential helpers:

sbx secret set-custom <NAME> --host <MAVEN_REPO> --env GCLOUD_TOKEN --placeholder gcloud_token \
  --command "gcloud auth print-access-token" --ttl 45m

The daemon/proxy would run the command on the host (as the invoking user) and use
its stdout as the secret value. Either refresh on the --ttl interval, or — perhaps
simpler — invoke it lazily at injection time with a short cache, in which case
--ttl is just the cache duration.

The placeholder mechanism already decouples the sandbox-visible value from the real
secret, so refreshes would be transparent to running sandboxes.

Environment

sbx version: v0.32.0 55580366449bcfebfc1787b9944284cf64c856d7

[kiview]

Thanks for the suggestion @cholpas, that makes total sense. We'll look into supporting that use case.