* Scroll into view before a forced click

`Compare tab: send to two panes` failed on a macOS runner with

    Locator.click: Element is outside of the viewport

then a cascade of TargetClosedError as the browser came down behind it. The menu
item existed and was found. It was simply below the fold: a Mac runner's window
is shorter than a Linux one and Compare sits at the bottom of a long menu.

`click(force = True)` turns off actionability checks, which is exactly what these
call sites want against a menu whose overlay would otherwise intercept the click.
It also turns off the scroll that brings the element into the viewport, and
Playwright will not click a point it cannot reach. So the flag was doing two
things and only one of them was wanted.

The forced clicks are not new -- they arrived with the composer redesign in #5891
and have always worked on Linux. What changed is #9264, which made the Compare nav
be found reliably instead of sampled for: before that the step often gave up
earlier with "Compare nav not found" and never reached the click. That PR is
correct; it surfaced this rather than causing it, the same way #9283 was going to
surface the picker's context-pin assertion once the shard stopped dying in apt.

click_forced keeps force and adds the scroll back. The scroll is best effort: an
element that cannot be scrolled -- fixed position, zero size -- should still reach
the click and fail there with Playwright's own message, rather than here with a
scrolling one that names the wrong problem.

Applied to all 17 forced clicks across the three drivers, not just the one that
failed. They are the same hazard on the same runners, and the guard would be
worth little if the file it was written for were the only one obeying it. The
guard is a source scan for the bare shape, so a new one fails here rather than
twenty minutes into a Mac job.

Driven against a fake locator: these tests run on browserless lanes, and the
ordering is the whole contract, so a stand-in that records call order tests it
exactly -- scroll before click, force preserved, a failing scroll not swallowing
the click, and a failing click still propagating.

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

---------

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

…shard (#9289)

#9283 stopped two of the four Chat UI shards asking for webkit's system
libraries at all, which is why extra and picker went from 14 minutes failing to
under 6 passing. The shards that genuinely drive webkit -- chat, banner and the
cross-browser indicator -- still pay the full price, and it is still the thing
taking them down:

  0 upgraded, 181 newly installed
  Need to get 102 MB/114 MB of archives
  Get:2 .../fonts-wqy-zenhei [7472 kB]   -> 4m51s, then the attempt died

Seen again today on a staging chat shard, after every other apt lever in this
repo had already been pulled. Bounding the wait cannot help: the work is a real
102 MB and the mirror was delivering 7 MB in five minutes.

So stop re-downloading it. apt keeps what it installed in /var/cache/apt/archives
until something runs `apt-get clean`, so the .debs are already sitting there at
the end of a good run. This copies them out, caches them on main, and copies them
back in before install-deps on later runs. apt checks each file against its index
and re-fetches only what does not match, so a stale entry costs a download rather
than a wrong install -- the failure mode is slow, not incorrect.

Keyed on the runner image as well as the engine set, because which .deb versions
satisfy a dependency set is a property of the image. Saved on main only, the same
rule as every other cache here: a PR-ref entry can only be restored by re-runs of
that same PR while still counting against the shared budget.

The engine guard from #9283 caught this change, which is the second time it has
earned its place. Its detector read step NAMES as well as run bodies, and this
step is named for the .deb set it holds -- webkit's -- so two chromium-only
shards suddenly looked like webkit users. Fixed in the detector rather than by
renaming the step: a `uses:` step cannot drive a browser, so only steps that run
something should count.