Let only main write the Gradle cache

[DimazzzZ]

Summary

Follow-up to #29, found by measuring the slow CI run you flagged (run 32030544289):

Job	Step	Time
Plugin Verifier	Verify plugin (3 IDEs, pre-#29)	7m27s
Plugin Verifier	Post Setup Gradle — uploading cache	1m44s
Test	Test (cold cache)	6m13s
Test	Post Setup Gradle	32s

#29 fixed the verifier side (one pinned IDE). This fixes the other half, which is systemic.

The cause

cache-read-only was pull_request && head.repo != base repo — i.e. it excluded forks only, so every same-repo PR wrote its own copy of the Gradle home. Measured state:

total: 24.01 GB across 60 entries   (GitHub budget ~10 GB)
refs/heads/main        14 entries
refs/pull/28/merge     18 entries
refs/pull/29/merge     17 entries

Over budget means LRU eviction, so entries were thrown away before they could ever be reused. Every run therefore paid twice: a cold restore and ~2 min of pointless uploading.

The change

PRs are read-only; only pushes to main write. This is the documented setup-gradle pattern, main already holds a full set of entries, and PRs can still restore the default branch's cache. It's also strictly safer — same-repo PRs can no longer poison the shared cache.

Also corrects a comment I added in #29 claiming the extracted IDEs aren't cached and would need their own cache action. They are — setup-gradle covers both the installers in caches/modules-2 and the extracted trees (there's a gradle-transforms-v1 entry, ~1.4 GB). Pinning verification to one IDE is what bounds the size, not any absence of caching. The reasoning in #29's commit message was wrong on that point even though its conclusion (don't add a second cache action) happened to be right.

Test plan

• YAML validates; both setup-gradle steps now resolve to cache-read-only: ${{ github.event_name == 'pull_request' }}; no stale fork condition remains.
• On this PR's own run: Post Setup Gradle should be short (no save) instead of 1m44s/32s.
• After it merges, the first main push reseeds the cache; the run after that should show a warm restore and a materially faster Test step than the 6m13s baseline.

Note the stale refs/pull/* cache entries should be pruned so the next run isn't competing with them for the budget — GitHub reclaims them when PRs close, but not promptly.