ci: write large actions/cache entries only on push to main

An actions/cache entry is scoped to the ref that wrote it: a run restores
from its own ref and from the default branch, and nothing else. So an entry
written from refs/pull/*/merge is visible only to another run of the same
pull request, and one written from the merge queue's gh-readonly-queue/*
branch is visible to nobody, because the queue deletes that branch when it
is finished with it. Both still consume the repository's shared cache
budget, which is evicted least-recently-used.

On 2026-09-15 the repository held 12.27 GiB across 14 entries: 9.22 GiB on
one gh-readonly-queue/* branch, 3.01 GiB on refs/pull/*/merge, and nothing
at all on main. Seven near-identical Linux-java-maven-* Maven repositories
accounted for 9.06 GiB of it, every one of them a write-only copy. With
main's cargo-ci entry evicted, all eight native builds in merge_group run
34977717057 missed their cache and paid a cold compile of 20 to 28 minutes
each, 259 runner-minutes in a single run. The same build on the push run two
hours later restored in 56s and compiled in 2m21s.

The two cargo saves in pr_build_linux.yml carried `if: github.ref ==
'refs/heads/main'` when this was written. #5963 has since replaced that guard
with `if: github.event_name == 'push'`, which also excludes the scheduled run
at the same sha, so both conditions are now spelled out together and
check_cache_save_scope can see the ref half. Hold every other large cache to
the same rule: a cache of ~/.m2/repository or of a cargo tree is restored
everywhere and saved only on push to main. The bare actions/cache@vN form
cannot express that, since it saves in an implicit post step no `if:` can
reach, so those sites split into actions/cache/restore plus a guarded
actions/cache/save.

The TPC-H and TPC-DS datasets keep the read-write form: they are a few
hundred MB, they are keyed on the workflow file, and a pull request editing
that file would otherwise regenerate them on every run. publish_snapshot.yml
keeps it too, since it runs from main on a schedule already.

check_cache_save_scope in dev/ci/check-ci-config.py pins both halves, and
rejects a new bare actions/cache@vN on any of those paths. Six mutations
were used to confirm it fails: reverting a site to the read-write form,
dropping the github.ref guard from each of four saves, and adding a fresh
unguarded cargo cache.

pyarrow_udf_test.yml now lists itself in its paths filter. It sits outside
the ci.yml umbrella, so compute-changes.py does not route it, and an edit to
the file merged without the workflow ever running -- including the cache
step changed here.