perf(ci): investigate Free Disk Space step — 47-67% of pre-build overhead — follow-up to #363

[scottschreckengaust]

Parent: #363 (build-performance umbrella). Surfaced by the measured re-review of PR #364 (@theagenticguy); needs maintainer approved before implementation (ADR-003).

Finding — the dominant, addressable pre-build cost

From authoritative per-step timings (gh api repos/.../actions/jobs/<id> .steps[].started_at/completed_at, not log arithmetic), the Free Disk Space step is 47–67% of the entire job-start → build pre-work:

Run	job	Free Disk Space	job start → build	share
30412723686	90452344735	148s	220s	67%
30419878840	90474296240	97s	179s	54%
30418865914	90471207016	75s	158s	47%

One sudo rm -rf step is roughly half the per-job overhead that the shard math (#675) treats as irreducible. It also deletes /opt/hostedtoolcache, after which Setup Node.js re-downloads Node 22.23.1 (Acquiring 22.23.1 … Adding to the cache) — only ~4–5s, so a smell rather than a cost, but the step pays ~100s to delete a tool cache it immediately needs part of back.

Scope — run the experiment the doc's own measurement protocol demands

• Not claiming the step is unnecessary — no ENOSPC evidence was seen in sampled logs, and absence of evidence is not proof the build fits without it.
• Experiment: drop the step (or narrow it to /usr/local/lib/android + /usr/share/dotnet, keeping /opt/hostedtoolcache), then report peak disk and 4-core wall time before/after with run IDs.
• If safe, this is the single highest-value CI change measured so far.

Why it leads

Cutting this drops fixed_overhead from ~120–220s toward ~60–100s — which is the one change that could make sharding (#675) worth re-costing before its ~250s trigger fires. So it sequences ahead of everything else.

Sequence (see re-ranked comment on #363)

#(this) Free Disk Space → #677 runner → #678 path-filter → #676 coverage → #684 cache-investigation → #675 shard (deferred).

Refs #363