statusline 'shim vX' reads package.json on disk, not the running shim, so every agent displays current while 22 of 26 run stale code

Found by Elazar in the CLI 2026-09-12, against a claim of mine. I told nw-venus-cc to verify a fleet-wide relaunch by checking that every agent's statusline reads shim v2.59.14. Elazar pointed out db-mars-cc already read v2.59.14 without having restarted, which makes the criterion one that always passes. MECHANISM: statusline-elazar.sh line 343 runs jq -r '.version' /opt/llmmsg-srv/package.json at RENDER time, refreshInterval 30, so within 30 seconds of that file changing every agent on the host displays the new number regardless of whether its own shim process ever restarted. The file's own comment block says it is read from the shim's SSOT rather than a constant, which is correct as far as it goes and is exactly why it reads as trustworthy - the defect is that the field is LABELLED as the shim version while measuring the package on disk. MEASURED: /opt/llmmsg-srv/package.json mtime 2026-09-12 05:19:11 UTC. Of 26 running llmmsg-srv-mcp.mjs processes on venus, FOUR started after it; 22 are executing pre-05:19 code while rendering v2.59.14, and the oldest has been up since Sep 5 - seven days. Per-agent, mapped by the session's cwd: db-mars-cc pid 764475 started Sep 11 10:25:04 (nineteen hours before the file changed), pmmaster-evolutiva-cc pid 2692949 started Sep 11 22:01:25. Both render .14. WHY IT MATTERS BEYOND COSMETICS: OPS-228 cut the llmmsg envelope by 102.8 chars per delivered message, roughly 60,500 tokens/day fleet-wide, and that saving accrues per agent ONLY on session restart because the shim is a per-session spawned process. So the field that looks like it answers 'did this agent pick up the new shim' is the one field that cannot, and it answers YES for everyone. FIX, two options, nw-venus-cc's call: either relabel it to name what it measures (for example 'srv v2.59.14' or 'pkg v2.59.14'), or make it read the RUNNING process - compare the session's own shim pid start time against the package.json mtime and render a marker when the process predates the file, which is the only form that answers the question a reader is asking. Prefer the second; the first is honest but leaves the useful question unanswerable from the statusline. WORKING CHECK meanwhile, for any relaunch verification: for p in $(pgrep -f llmmsg-srv-mcp); do pp=$(ps -o ppid= -p $p|tr -d ' '); echo "$(ps -o lstart= -p $p) $(basename "$(readlink /proc/$pp/cwd)")"; done - any shim older than stat -c %Y /opt/llmmsg-srv/package.json did not pick up OPS-228. PATTERN, same night, third instance: an instrument reading an adjacent artifact and presented as a claim about the thing itself, failing toward the reassuring answer. OPS-226 was a footer regex deciding BUSY, OPS-230 was an adjudications file degrading to zero suppression silently, and this one says everyone is current.