feat(plugin-go): the shared golist GOCACHE becomes a declared scratch

[raphaelvigee]

Third of three (on top of #434). The retrofit that proves the mechanism.

plugin-go's golist_gocache.rs was this feature, implemented once, for one
driver, by hand: a directory under the engine home keyed by a hand-written
struct, with no lock, no eviction, no remote, no visibility, and available to
nothing else. It is now an ordinary scratch target —
//@heph/go/gocache:cache@<factors> — which supplies all of those.

The provider serves it from an early handle_get arm, before package decoding,
exactly as the hermetic toolchain is served: there is no such directory on disk,
and asking the filesystem about it would only produce a confusing "not found".
The golist driver takes a scratch reference and reads the mount off RunRequest
instead of resolving a directory itself.

This is the design's acceptance test — if the general mechanism cannot express
the special case, the design is wrong. It can, with one correction worth stating
plainly.

GOROOT leaves the key, and that is an improvement

The old key included the resolved GOROOT path, because Go's action IDs
incorporate it. A scratch declaration is resolved before the driver runs and
GOROOT is not known until it has — so the path cannot be in the key.

Dropping it is not a loss:

• Under gotool: "host", GOROOT is a function of the Go version, which is in
  the key. Nothing changes.
• Under a hermetic toolchain the SDK stages at a different absolute path in
  every sandbox, so the old key gave every sandbox its own slot and every one of
  them fell back to cold. Dropping the path gives them one shared slot.

It does not make a hermetic build's action IDs match across sandboxes —
those still embed the staged GOROOT — so the win there stays bounded until the
SDK is staged at a stable path (see hermetic-goroot-stable-path). It does mean
the cache stops being fragmented for no reason.

The remaining factors (go version, goos, goarch, build tags, goexperiment, race)
live in the addr as readable args rather than a hash, because they show up in
heph tool scratch ls and "which cache is this?" is a question a hash cannot
answer. The engine keys the slot on the addr, so two runs agreeing on every
factor share a directory and two that disagree on any of them do not — asserted
per factor.

access = "shared", because Go's build cache is content-addressed and
self-verifying and concurrent access is what go build -p N already does;
serializing it would turn the 2.4× into a large loss. That property was
previously expressed by having no lock at all; it is now stated.

Local-only for now. Publishing a Go build cache is worth doing and is a separate
change with its own before/after, since whether the transfer beats a cold
go list is a measurement rather than a guess.

What still needs a number — please label this perf-test

.github/workflows/perf.yml runs on a PR labelled perf-test and times a
500-package Go corpus against N−1 across cold / full-hit / incremental.

cold is the scenario that matters here. The 2.4× was always an intra-run
win — 500 packages sharing one GOCACHE within a single cold build — and cold
wipes .heph3 on both sides, so it measures like for like. This change should be
neutral-to-better there.

That is a claim for the gate to settle, not for a local run. The seeded-GOCACHE
experiment on this same corpus cut go list CPU by 60% and moved wall time by
exactly zero, which is the standing reminder that an obvious cache win here
can be worth nothing.

Note the label does not retrigger the job on an already-open PR (pull_request
fires on opened/synchronize/reopened, not labeled) — label, then push or
re-run the job.

Safety

A missing mount falls back to a sandbox-local directory rather than failing: an
older host that does not carry scratch mounts on RunRequest must still be able
to run this driver, and a cold cache is slow, never wrong.

Not in this PR

The other three Go sites, each wanting its own number:

• driver_compile.rs still creates a per-sandbox .heph-gocache — the same
  pattern this removes for golist, left behind because that fix was driver-local.
  Smaller upside (§2 measured all compilation at 15s against golist's 778s).
• thirdparty.rs's GOMODCACHE/GOPROXY host passthrough — the largest CI
  effect, and the only one that narrows a hermeticity hole rather than widening
  one.
• pkg_analysis.rs enumerates those vars for hashing and moves with them.