Stop CodeQL from filling the repository's Actions cache quota

[mernst]

The repository held 10.78 GB of Actions caches against a 10 GB quota, so GitHub was evicting caches that jobs were about to use. This is why #8230's Gradle caches would not have survived on their own.

Where the 10.78 GB went:

Family	n	GB	Owner
codeql-dependencies-*	5	5.18	CodeQL default setup
gradle-modules-*	8	2.93	CI workflow (addressed in #8230)
setup-java-*-gradle*	9	1.34	prek.yaml
codeql-overlay-base-database-*	7	0.79	CodeQL default setup
`prek-v1	Linux	X64`	1
gradle-wrapper-*	1	0.15	CI workflow

Default setup replaced by advanced setup

Default setup enables Java dependency caching automatically and exposes no way to turn it off. Advanced setup — this workflow — makes dependency-caching configurable, and it is set to false here.

Each such cache holds about 1 GB of ~/.m2/repository and ~/.gradle/caches, and its key covers every *.gradle file in the repository, so any build-file change mints a fresh gigabyte while the old entry lingers. Five coexisted.

The workflow reproduces what default setup was configured to do: languages actions, java-kotlin, and python; the default query suite; a weekly schedule; and category: /language:<language>, so existing alerts keep their identity rather than being reported as new.

⚠️ Merging this requires disabling default setup first

Code scanning is currently in default setup (gh api repos/typetools/checker-framework/code-scanning/default-setup reports state: configured). An advanced-setup workflow cannot upload results while default setup is enabled — CodeQL rejects the SARIF with "analyses from advanced configurations cannot be processed when the default setup is enabled". So the CodeQL job on this very pull request is expected to fail until default setup is switched off, in Settings → Code security → Code scanning.

I did not flip that setting, since it briefly leaves the repository without code scanning and it is a repository-wide security setting.

One consequence worth weighing

Disabling dependency-caching means CodeQL re-resolves Java dependencies from Maven Central on each analysis. There were 35–39 analyses per day over the last few days, roughly a third of them java-kotlin, so this adds on the order of 12 GB per day of Maven Central traffic — which cuts against #8230, whose purpose is to stop provoking Maven Central into returning HTTP 403.

If that trade is not worth it, this pull request can simply be dropped: #8230's shared module cache, plus deleting stale caches, already bring the total under quota, though with CodeQL occupying most of it.

Already done by hand

11 stale caches, about 3.3 GB, were deleted: merged #8207's CodeQL cache, the deleted renovate/gradle-9.x branch's caches, superseded setup-java entries on master, stale per-commit CodeQL overlay databases, and the oldest CodeQL dependency cache. Open pull requests' caches were left alone. The repository now sits at 7.89 GB.

🤖 Generated with Claude Code

[mernst]

Dropping this. Disabling CodeQL's dependency-caching would make CodeQL re-resolve Java dependencies from Maven Central on each of roughly a dozen java-kotlin analyses per day, which works against #8230's purpose of not provoking Maven Central into returning HTTP 403. Code scanning's default setup has been restored.

#8230's shared Gradle module cache, plus deleting about 3.3 GB of stale caches, already brought the repository from 10.78 GB to under the 10 GB quota.