fix(cowshed): standard clients authenticate to the egress proxy

Inside `cowshed exec`, any cargo command that needed the crates.io
registry ground for minutes through `spurious network error ... CONNECT
tunnel failed, response 401` before failing. Two independent causes,
both fixed here.

The credential had no channel. The supervisor exported HTTP_PROXY
and its three siblings as a bare `http://127.0.0.1:<base>`, while
the gateway authenticates every request with `Proxy-Authorization:
Bearer <workspace-token>`. No standard client can be told to add that
header to a CONNECT, so every tunnel was rejected unauthenticated, and
cargo classifies the resulting libcurl CURLE_RECV_ERROR as spurious
and retries its whole ladder. curl, libcurl (so cargo), reqwest, and
Go do all read `user:password` out of the proxy URL and send it as
`Proxy-Authorization: Basic` on the first CONNECT, preemptively, so the
token now rides as userinfo (`http://cowshed:<token>@127.0.0.1:<base>`)
and the gateway accepts `Basic` as a second spelling of the same
credential, through the same constant-time comparison. The username is a
fixed label and is not compared. This exports no authority the sandbox
lacks: COWSHED_WORKSPACE_TOKEN is already in the same environment,
and the token authenticates against nothing but that workspace's own
loopback endpoint.

The rejection was also the wrong status. An unauthenticated request
got 401 — which claims the *upstream* demanded authentication,
carries no challenge, and gives a client nothing to act on. It is now
407 with `Proxy-Authenticate: Basic realm="cowshed"`, emitted from
`problem()` so no authentication failure can omit it. 407 does not
by itself escape cargo's retry ladder — libcurl maps every non-2xx
CONNECT response to CURLE_RECV_ERROR, which cargo's `maybe_spurious`
treats as retryable regardless of status — but it is the answer
a credentialed client can act on, and it keeps the failure at one
round trip.

Third, `$CARGO_HOME` follows the private HOME the supervisor exports,
so every workspace faced an empty `~/.cargo` and refetched crates the
host already had, one CONNECT at a time. The host's `registry/index`
and `registry/cache` are now linked into the private HOME read-only,
admitted by a Seatbelt read grant on the host path (Seatbelt matches
resolved paths, so the link alone is inert), while `registry/src`
stays a real writable directory inside the mount so unpacking still
works and copy-on-write hands a warm one to every clone. `~/.cargo`'s
config, credentials, and bin remain hard denies.

Live proof in a throwaway adopted workspace: `cargo build --offline`
resolved and built libc 0.2.189 from the host registry with no network;
in-sandbox curl using the workspace's own exported proxy credential
completed an authenticated CONNECT through an intercepted grant (200),
and the same request with the credential stripped returned 407 in 14 ms.