[Bug]: Storage cleanup overstates recovered space for worktrees with hardlinked dependencies (pnpm) #17815

Before submitting

• I searched existing issues and did not find a duplicate. (The size fields were added in fix(storage): make worktree cleanup work and show why it skipped #17563.)
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Use a project that installs dependencies with pnpm (or anything else that hardlinks from a shared store). Create a thread in a new worktree and run the install there.
2. Compare what the worktree appears to hold with what removing it would release:

   # what the report counts
   find "$WORKTREE" -type f -printf '%s\n' | awk '{s+=$1} END {printf "%.2f GB\n", s/1e9}'
   # files that exist nowhere else
   find "$WORKTREE" -type f -links 1 -printf '%s\n' | awk '{s+=$1} END {printf "%.2f GB\n", s/1e9}'

3. Note free space with df, let storage cleanup remove the worktree (for example delete the thread with Delete worktrees with deleted threads on, then Delete now), and compare the change in free space with the size shown in Settings → Storage.

The cause, in apps/server/src/storageCleanup.ts on main: measureWorktree adds stat.size for every regular file (line 233). A file hardlinked into the worktree from the pnpm store is counted in full, although removing the worktree only drops one link and frees nothing. That number becomes the entry's bytes and is summed into bytesFreed.

Expected behavior

The per-worktree size and the "recovered" total reflect space that removal actually releases, or are at least a lower bound on it.

Actual behavior

Measured on two live worktrees:

The first is overstated about tenfold. Watching df while cleanup worked through a backlog, the first 69 removals changed free disk space very little and the next 19 freed about 11 GB.

Impact

Minor bug or occasional failure

Version or commit

T3 Code Nightly 0.0.46-nightly.20261010.2922. Code read at main @ f7664fd.

Environment

Linux desktop host server, pnpm projects.

Workaround

None. The figure in Settings → Storage cannot be relied on for pnpm projects.

Suggested direction

FileSystem.File.Info already exposes nlink and blocks as Options, so no extra syscall is needed. Count a file only when nlink is 1, prefer blocks * 512 over size, and fall back to size when either is unavailable (Windows).

This undercounts a file whose only other link is in another worktree rather than the store, which is the right direction for a "recovered" figure. The existing test "measures nested regular files without following symlinks" could gain a file hardlinked from outside the worktree.