Stop the test build filling the runner's disk

The desktop job died mid-link with LLVM reporting "IO failure on output
stream", which reads like a compiler crash and is not one: underneath it
is `No space left on device`. The runner ran out of disk while linking.

Worth knowing what it was spending it on. `target/debug` was 24 GB
against `target/release`'s 2.6 GB -- the test build is roughly ninety
percent of the footprint -- and of that, 15 GB was debug info in
`debug/deps` and 3.6 GB was incremental state. Neither buys anything
here. Nothing attaches a debugger to a CI run, and incremental
compilation exists to make the second build in a working tree fast,
which is not a thing a fresh checkout ever has.

With both off the same tree is 3.3 GB, `debug/deps` 2.8 GB, and the test
binaries build unchanged. Backtraces keep function names and lose file
and line numbers; if a failure ever needs those, DEBUG=1 gives line
tables back for a fraction of the 15 GB.

A `df -h` either side of the expensive steps, so the next time this
happens it says so in one line rather than as an error from LLVM.

This is a mitigation and it should not be mistaken for the fix. It bounds
what this job asks for; it cannot help if the runner is full of anything
else, and 24 GB of build output is not obviously the largest thing on a
host that also keeps every cached target directory this workflow has ever
saved. If it fails here again, the disk needs looking at on draco-x86.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.gitea/workflows/build-and-test.yml

@@ -27,6 +27,30 @@ jobs:
     container:
       image: catthehacker/ubuntu:act-latest
 
+    # This job filled the runner's disk and died mid-link with "No space left
+    # on device" — LLVM reporting an IO failure on its output stream, which
+    # reads like a compiler crash and is not one.
+    #
+    # `target/debug` was 24 GB against `target/release`'s 2.6 GB: 15 GB of it
+    # debug info in `debug/deps`, 3.6 GB incremental state. Neither earns its
+    # space here. Nothing attaches a debugger to a CI run, and incremental
+    # compilation exists to make the *second* build in a working tree fast,
+    # which is not a thing a fresh checkout has. Turning both off is the
+    # standard CI setting rather than a trick.
+    #
+    # Measured on this workspace: the same `cargo test --workspace --no-run`
+    # tree goes from 24 GB to 3.3 GB, `debug/deps` from 15 GB to 2.8 GB.
+    #
+    # Backtraces still name functions without debug info; they lose file and
+    # line numbers. If a test failure ever needs those, drop DEBUG to 1
+    # (line-tables-only) rather than back to 2.
+    #
+    # This is a mitigation, not a fix. If the runner is full of anything other
+    # than this job's own output, it will still be full afterwards.
+    env:
+      CARGO_INCREMENTAL: 0
+      CARGO_PROFILE_DEV_DEBUG: 0
+
     steps:
       - name: Checkout
         uses: actions/checkout@v4
@@ -101,6 +125,12 @@ jobs:
             --default-toolchain 1.92.0 --component rustfmt,clippy
           echo "$HOME/.cargo/bin" >> "$GITHUB_PATH"
 
+      # Free space before and after the expensive steps, so a repeat of the
+      # disk exhaustion above is one line to diagnose instead of a puzzling
+      # LLVM error.
+      - name: Disk before
+        run: df -h /workspace 2>/dev/null || df -h .
+
       - name: Format
         run: cargo fmt --all -- --check
 
@@ -116,6 +146,10 @@ jobs:
       - name: Build
         run: cargo build --workspace --release
 
+      - name: Disk after
+        if: always()
+        run: df -h /workspace 2>/dev/null || df -h .
+
   android:
     runs-on: linux/amd64
     name: Android (aarch64)