ci: bust the re-poisoned cargo cache (v3) + burst-guard the runner prune

This session's push storm refilled the runner to 100% WITHIN the prune timer's 24h window
(it only trims >24h), so a build hit ENOSPC and actions/cache saved a truncated target/ ->
`error[E0463]: can't find crate for shlex` in ci.yml's clippy. Two fixes:

- Bump cargo-target-v2- -> v3- in ci.yml + deb.yml so the poisoned tarball is bypassed (a
  suffix bump can't — restore-keys falls back to the old prefix; same as the v1->v2 fix).
- Harden scripts/ci/docker-prune: run HOURLY (was 6h) with a burst guard — if the disk is
  still >85% after the normal until=12h trim, prune ALL idle images + build cache (in-use
  protected). A fast push-burst can fill 99 GB inside any time window, so the disk-pressure
  trigger, not the age filter, is the real backstop. Applied live on home-runner-1 (reclaimed
  95%->66%) and checked in.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

.gitea/workflows/deb.yml

@@ -71,10 +71,10 @@ jobs:
       - uses: actions/cache@v4
         with:
           path: target
-          # -v2-: bypass a target cache poisoned by a disk-full build (see ci.yml). Shares the
+          # -v3-: bypass a target cache poisoned by a disk-full build (see ci.yml). Shares the
           # key with ci.yml so the release build reuses its clean artifacts.
-          key: cargo-target-v2-${{ env.rustc }}-${{ hashFiles('Cargo.lock') }}
-          restore-keys: cargo-target-v2-${{ env.rustc }}-
+          key: cargo-target-v3-${{ env.rustc }}-${{ hashFiles('Cargo.lock') }}
+          restore-keys: cargo-target-v3-${{ env.rustc }}-
 
       - name: Build release host + client
         env: