Disable uv caching for stubsabot

[AlexWaygood]

Stubsabot and the regression-test job currently use the same uv cache key. GitHub shares caches between workflows on the same branch, so stubsabot's scheduled runs on main can restore caches populated by test runs on main. The test jobs' contents: read permission does not prevent them from saving caches.

This creates a potential privilege-escalation path:

1. An attacker compromises a test-only dependency or its build backend. Installing it during an otherwise ordinary CI run triggered by a push to main can execute the attacker's code without a malicious change being merged into typeshed.
2. That code modifies cached files that a later stubsabot run will use. When a new cache entry is saved, for example after cache invalidation or eviction, the poisoned files become available to other workflows on main.
3. Stubsabot restores the cache and executes the affected code with its persisted SSH key and its GITHUB_TOKEN with pull-requests: write available. The attacker could steal those credentials, push commits wherever the SSH key is authorized, and create or modify PRs. Whether this permits a direct push to main depends on the key's permissions and branch protections; it does not inherently bypass those protections.

The prerequisite is code execution in a job that can populate main's cache scope. An ordinary fork PR cannot write to that scope: its caches are isolated under the PR's merge ref. See GitHub's cache access and security documentation.

This PR disables uv cache restoration and saving for stubsabot, removing this route from test jobs into the more privileged bot while leaving test-job caching unchanged.

Created with Codex.

[srittau]

Makes sense to me.