[Feature] Supporting dstack-inside-dstack for runs

[peterschmidt85]

Problem

Runs may need to call dstack themselves, for example to inspect runs, submit
another run, or attach to it. This currently requires the dstack server to
accept direct connections from the run.

UX

Add dstack: true to a run configuration.

type: task
image: dstackai/dstack
dstack: true
env:
  - DSTACK_TOKEN
commands:
  - dstack ps

With dstack: true, dstack exposes the server managing the run through
/run/dstack/server.sock inside each job. It sets DSTACK_SERVER_URL to the
corresponding http+unix URL and DSTACK_PROJECT to the current project,
allowing the CLI and API clients to use that connection.

Authentication remains explicit. dstack does not inject DSTACK_TOKEN; it can
be passed through the existing environment or secret mechanisms.

The CLI also accepts DSTACK_SERVER_URL, DSTACK_PROJECT, and DSTACK_TOKEN
as a complete configuration without requiring ~/.dstack/config.yml.

dstack cannot be combined with inactivity_duration on dev environments,
since the persistent server connection counts as activity.

Implementation

Before starting commands, the server opens an SSH connection to each job and
creates a remote Unix-socket forward. Connections to
/run/dstack/server.sock inside the job are forwarded to the HTTP port of the
server managing the run. DSTACK_SERVER_URL points clients to this socket.

This uses the existing job SSH path, so the server does not need a public URL
or gateway. Health checks use the same socket path end to end; if the SSH
connection or socket becomes stale, the server closes and recreates the
tunnel. The tunnel is removed when the job terminates.

With multiple server replicas, a replica probes the socket and adopts an
existing healthy one instead of overwriting it, so jobs keep a single stable
server owner.

[jvstme]

The run configuration option and the connection pool implementation look good to me. Haven't looked at the rest