fix(statusline): move the usage fetch off the render path

[asdf8675309]

What

Location and weather already refresh in detached background subshells. The comment above them says why:

This replaces the original synchronous design that did curl --max-time 3 on the render path during cache expiry — that's what killed the perf and got the feature ripped out on 2026-05-08.

The usage fetch is the last one still inline. Every 900s the mutex winner runs security find-generic-password and a curl --max-time 3 while the bar renders. If that endpoint is slow, the render sits there waiting.

Measured against a blackholed endpoint so the curl burns its full timeout: 3.36–3.49s per render, against a shipped refreshInterval of 1.

The part that bites on macOS

Those seconds are a kill window — Claude Code terminates a render that overruns its interval (#1767 covers what the killed renders leave behind).

security is the bad one to get killed inside of. It prompts through readpassphrase(), which opens /dev/tty directly and flips the terminal to canonical no-echo mode. Kill the render mid-call and the terminal can stay that way. What you get is a session where arrow keys spray escape sequences, backspace stops echoing, and what you type goes into a password buffer instead of the prompt — so hitting enter answers a keychain challenge you can't see.

Worth noting: the 2>/dev/null on that line can't prevent any of it, because the prompt goes to /dev/tty, not stderr.

</dev/null on the detached subshell removes the path entirely. The fetch can't read the terminal because it no longer has one.

Change

Wrap the fetch in the same ) </dev/null >/dev/null 2>&1 & + disown shape the weather block already uses. Two things had to change to keep @lmbagley's mutex from #1349 intact.

Ownership token. Bash 3.2 has no BASHPID, and $$ inside a subshell still names the parent — which exits in milliseconds. Writing $$ would let the next render's liveness check reap a lock whose fetch is still running. sh -c 'echo $PPID' returns the subshell's own pid:

parent_shell_pid=61010
parent_sees_bang=61011
  inside_subshell: dollar_dollar=61010  sh_c_PPID=61011  BASHPID=UNSET

sh_c_PPID matches the parent's $!. That's the value that goes in the pid file, so kill -0 still reads a live process.

Release. Moved to an EXIT trap so a killed fetch can't leak the mutex. It still verifies ownership before removing anything, same as before.

Why it's safe

_data_age never reaches 0 on this render now, so the winner takes the same path the mutex losers already take: last-known-good with an honest age, fresh data on the next tick. That path is already there and already exercised.

The forced-refetch bookkeeping restores _orig_age, which is correct — from this render's point of view the attempt hasn't landed yet, and the comment there already says a non-landed attempt should restore the true age.

Everything else is untouched: the fail-closed .five_hour probe, the atomic fetched_at-stamped write, the symlink guard, the dead-owner reap, the 900s TTL and the scoped fast lane. _tmp_cache now keys off the fetch pid instead of $$, which is strictly more unique.

Verification

macOS 15 (Apple Silicon), bash 3.2.57. Both arms get test-only cache and lock paths plus a blackholed endpoint, so nothing touches live state and the curl always burns its full 3s.

	Render 1	Render 2
stock	3.49s	3.36s
patched	0.29s	0.27s

Lock behavior on the patched build:

t+0.0s  lock HELD by detached fetch, pid=81648
        owner alive? YES
t+5.0s  lock RELEASED cleanly

bash -n exits 0.

Portability of the ownership token. The token has to equal the parent's $! or the liveness reap can kill a live fetch, so I checked it on both shells LifeOS runs on, with both common /bin/sh implementations:

shell	/bin/sh	token	parent $!	match
bash 3.2.57	sh	14313	14313	yes
bash 5.3.15	sh	14322	14322	yes
bash 5.3.15	dash	14331	14331	yes
bash 3.2.57	dash	14340	14340	yes

BASHPID resolves to the same value on 5.3.15, so one code path is correct on both and there's no need for a platform branch. dash sets $PPID correctly, which matters because it's /bin/sh on Debian and Ubuntu. Everything else in the diff is POSIX apart from disown, which the weather block above already uses with the same 2>/dev/null || true guard.

Linux gets a smaller version of the same win. It takes the .credentials.json branch, so there's no security call and no terminal to strand — but the curl is still on the render path, and #1767's report came from a headless Ubuntu box where killed renders were the problem.

Control for that last line. "Released cleanly" is a pass-by-absence, so I checked it can fail: strip the EXIT trap, leave everything else, re-run. Mutation counted (trap lines 1 → 0), sabotaged script still parses, and the lock leaks. The check isn't blind.

The stock arm is its own control for the latency number — same harness, same endpoint, 12x the wall time.

Scope

Left alone on purpose:

• DeployComponents.ts and the refreshInterval default. That's fix(installer): raise the shipped statusline refreshInterval from 1s to 30s #1772. This PR stands on its own — a render that doesn't block is worth having at any interval.
• The /tmp/pai-parallel scratch dirs. fix(statusline): bound the /tmp pai-parallel leak (follow-up to #1297) #1767 owns that. No overlap: different function, different region of the file.
• The 2>/dev/null on the keychain read. Inside a detached subshell everything already goes to /dev/null, so changing it would be noise.
• USAGE_CACHE_TTL and the scoped fast lane. Not my call to retune, and detaching doesn't depend on it.

One thing I noticed but didn't act on: the comment at L859 says "the 5s tick rate must never hammer it," so the script was written expecting a 5s tick while the installer ships 1. That mismatch is what #1772 is about.