Add a system-library capability that ships Chromium's shared libraries #66

Jobs that run a browser (Playwright's Chromium, in our case) install its shared libraries with apt on every run. The pods are ephemeral and start without them, so each job fetches the packages from the Ubuntu mirror for its architecture. The fleet mixes x86-64 and arm64 pods, and the two paths differ: arm64 packages come from ports.ubuntu.com, amd64 ones from archive.ubuntu.com. The arm64 path has been slow enough to fail the job: on two runs of one pull request, all three install attempts timed out at the step's five minute cap before any test ran, with a single 5.6 MB package taking over two minutes while name resolution worked and the cluster's DNS logged no timeouts. The same step passes on a re-run, which makes it look like a flake and costs a queue slot each time.

The system-library capability mechanism already covers this shape of problem (a relocatable prefix copied into the pod by an init container, as for libpq). A capability image holding the libraries Chromium links against, resolved the way playwright install-deps chromium resolves them for the pod's Ubuntu release and architecture, would let a job skip apt entirely: the loader finds them through the pod's library path and the job needs no package fetch.

Open points: how the prefix is built from the .deb closure (extracting the archives into a prefix is the obvious route), which Ubuntu release it must match, with a prefix for each of the two architectures, and how it is kept in step with the Playwright version a consumer pins, since the library list changes between Playwright releases. A consumer-side cache of the downloaded archives removes the mirror from warm runs but not from the first one on a cold cache, which is why this belongs in the runner as well.

The same mix bit the consumer's browser cache: a cache saved by an x86-64 pod and restored on an arm64 one (or the reverse) held the other architecture's Chromium build under the same directory name, Playwright took the existing directory as installed, and the suite failed for want of the executable. A capability image has to be published per architecture and selected by the pod's own, as the existing tool images are.