fix(test): serve integration test leaks a ~57MB temp dir per run — 1,123 dirs / 62.5 GB took the machine to ENOSPC

[MichaelTaylor3d]

Task

dig-node's serve integration test creates a temp directory per run and never removes it. It
accumulated 1,123 directories totalling 62.5 GB in %LOCALAPPDATA%\Temp, which took the dev machine
to 81 MB free on a 1.9 TB disk and produced a machine-wide ENOSPC that stopped an unrelated lane
mid-build.

Make the test clean up after itself.

Measured

1,123 dirs  dig-node-serve-test-<pid>-<n>   62.47 GB   (~57 MB each)

Deleting them recovered the disk from 81 MB → 66.5 GB free.

The same Temp tree holds ~38,000 further leaked dirs from sibling tests, near-zero bytes each but real
filesystem clutter:

dirs	bytes	prefix
9,898	~0	dig-tip*
6,832	~0	dig-node-auth*
6,701	0.77 GB	dig-node-test*
5,683	~0	dig-node-custody*
3,659	0.01 GB	dig-wallet-sup*
2,585	~0	dig-wallet-rpc-authgate*
1,354	0.07 GB	dig-wallet-svc*

dig-node-serve-test is the only one that matters for space; the rest matter because 50,000 entries
make every Temp scan slow and make the real leak hard to see. Fixing the shared helper likely fixes all
of them at once.

Why this is a defect and not housekeeping

It took down a machine. ENOSPC is a CLAUDE.md hard STOP (§1.6, §1.7): the lane that hit it correctly
refused to free space by deleting a sibling lane's target/, so it had to stop and hand back. Every Rust
lane on the machine was blocked until an orchestrator intervened.

It is also self-concealing: the leak grows fastest exactly when the test suite runs most, so it
surfaces during heavy development and looks like a build-cache problem. The first diagnosis here blamed
worktree target/ dirs — which totalled ~25 GB across six worktrees and were not the cause.

Likely shape of the fix

Use an RAII temp-dir guard (e.g. tempfile::TempDir) rather than a constructed path, so cleanup happens
on drop including on panic. Note the related trap already recorded in this repo: a cleanup placed
after an .await leaks on panic if anything catches it — the guard must own the directory, not a
deferred cleanup step.

If a test deliberately preserves its dir on failure for diagnosis, that is legitimate — but it must then
be bounded (keep the last N, or delete on success) rather than unbounded.

Done condition

Run the serve integration suite twice and show the Temp dig-node-serve-test* count returns to its
pre-run value. A test that asserts its own cleanup is better than a manual check.

Scope

The temp-dir lifecycle in the test helpers. Do not widen into the tests' actual assertions.

Effort

Low-to-medium — one shared helper, but verify it covers the panic path, which is where this class
normally survives a fix.

[MichaelTaylor3d]

Cleanup performed to clear the ENOSPC (does not fix the leak — the tests still create these):

 1,123 dirs  dig-node-serve-test*   62.47 GB   deleted
38,495 dirs  the sibling prefixes    ~0.85 GB   deleted
-------
Temp subdirs 50,049 -> 10,433      free 81 MB -> 67.28 GB

Only dirs older than 2h were removed, so no live test lost its directory.

Worth noting for whoever takes this: the sibling prefixes are ~38k dirs holding under a gigabyte between them, so they cost almost nothing in space — but they are what made the real leak hard to find. A big-subdir listing showed only ~10 GB of the 76 GB because the leak is many dirs rather than large ones. Grouping by name pattern is what exposed it:

Get-ChildItem $env:TEMP -Directory -Force |
  Group-Object { ($_.Name -replace '[-_]?\d+','#') } |
  Sort-Object Count -Descending | Select-Object -First 10

If the shared helper is the common cause, fixing it closes all of them at once.

[MichaelTaylor3d]

Lane claimed. Branch loop/360-367-batch, draft PR #368 (batched with #360 #361 #363 #364 #367). Base 4efa57f, v0.154.0 -> 0.155.0. Will comment the outcome here.

[MichaelTaylor3d]

Shipped on #368 (8db320a)

A NodeCache RAII guard now owns the tree (tempfile::TempDir), so removal happens in Drop,
including on an unwind. Both leaking sites in content_serve.rs are covered --
dig-node-serve-test-* and dig-node-origin-test-*; the second was not in the ticket and was
leaking the same way. Ownership rather than a cleanup call, exactly as the ticket warns: a cleanup
line at the end of a test is skipped by every failing assertion, i.e. the runs a developer repeats.

There is no shared helper -- the common cause is the PATTERN

The ticket guessed at one. There is none: every site is a hand-rolled
env::temp_dir().join(format!(..)), ~50 across the workspace. But one sibling prefix pair does
share a helper worth naming -- dig-node-auth* and dig-node-custody* both come from
dig-node-core/src/peer.rs's fresh_pool_handle_on(tag, ..), which builds dig-node-{tag}-{pid}.

This PR fixes the space leak only, which is the defect that took the machine down. The rest is a
named follow-up rather than an unbounded sweep: dig-node-test-* (0.77 GB, tests/server.rs, 4
sites whose base outlives the block creating it, so it needs a signature change), peer.rs's tag
helper, and dig-wallet's dig-wallet-svc / dig-wallet-sup / dig-tip / dig-watchlist.

The honest residue, and why it is bounded rather than zero

The detached axum task still holds wallet.sqlite open when the test body returns, and Windows
will not unlink an open file, so TempDir::drop cannot remove that last ~1 MB. Drop cannot
cancel the task -- cancelling needs the runtime to poll it, and Drop cannot .await. So it is
bounded instead of pretended away: a once-per-process sweep removes trees idle for 15 minutes, which
no live run can be (the suite takes ~2.5 min). The ticket names bounded as acceptable.

How the leak was proved fixed

Measured on the same machine, full suite, twice each way:

	before	after
per-run residue	~970 MB (17 nodes x 57 MB)	17 MB
accumulated	62.5 GB / 1,123 dirs	swept to a 15-minute window

A leak test bounded by its own duration proves nothing, so neither test is one -- both assert on
the PATH, after the guard is gone:

• the_temp_tree_is_removed_on_drop_and_on_panic -- absent after a normal drop AND after a real
  catch_unwind unwind. Asserting Drop was reached would pass for a Drop that called
  remove_dir_all and swallowed the error, which is this type's exact silent failure mode.
• the_sweep_removes_an_abandoned_tree_and_spares_a_live_one -- three actors: an abandoned tree, a
  live tree, a stranger's directory. The live tree is the load-bearing one: a sweep that removed
  everything would satisfy "the stale one is gone" while deleting a concurrent lane's working
  directory, turning a disk fix into a flaky-failure generator elsewhere.

Four reverts, each applied alone (commit first, restore from a file copy -- never git checkout):

revert	assertion that fires
TempDir::into_path() in Drop (consumes without deleting)	"a guard dropped normally left its tree at ..."
the same, but only if std::thread::panicking() -- a deferred cleanup line	"a panic unwound past the guard and left its tree at ... -- this is the ENOSPC defect"
age check removed (sweep everything)	"the sweep deleted a tree young enough to belong to a running test"
age predicate inverted (spare everything)	"the abandoned tree survived, so the count grows without bound"

The second matters most: the first fires on the normal assertion, so on its own it does not prove
the panic half at all. Modelling a deferred cleanup separately is what proves it.

[MichaelTaylor3d]

Follow-up for the remaining prefixes (bounded, named list of 8): #370 — dig-node-test-* (0.77 GB) is the only one left with real bytes.