fix(statusline): inject plan-usage telemetry via ephemeral CLI flag, never disk

[timkjr]

Summary

The plan-usage chip's statusLine exporter was written into the case's .claude/settings.local.json. That file-based statusLine took precedence over the user's own global/project statusline for anyclaude invocation in that directory — including entirely outside Codeman — with no disclosure in the App Settings UI (labeled only as a header-display toggle) and no way to remove it once written (the removal code path was dead code: nothing ever called applyStatusLineConfig(path, false)).

Fixes this by injecting the exporter as an ephemeral claude --settings '{"statusLine":{...}}' CLI flag, resolved fresh at spawn time and merged with effort/ultracode into one --settings object (Claude Code accepts only one --settings flag per invocation). Never touches disk, so a plain claude run outside Codeman is completely untouched. Self-healing: a legacy disk-written exporter from an older build is stripped the first time a session starts in that workspace again. Still respects a user's own hand-authored statusline — it's never overridden.

Bonus: since the exporter no longer lives in a fixed file, it can now wrap the user's own real statusline instead of just backing off. findEffectiveUserStatusLineCommand() walks Claude Code's actual settings precedence (project settings.local.json → project settings.json → user ~/.claude/settings.json) to find whatever's really configured, and the shared exporter script fires the telemetry POST in a background subshell (confirmed non-blocking, ~4ms, even against an unreachable endpoint) then execs the user's real command with the same stdin — so the user keeps seeing their own statusline, and the plan-usage chip still gets its data.

A subtler bug found mid-fix

The exporter's command legitimately depends on $CODEMAN_SESSION_ID / $CODEMAN_API_URL / $CODEMAN_HOOK_SECRET_FILE and an internal $INPUT, all meant to be expanded only when Claude Code itself executes the statusline, using the pane's tmux setenv'd environment. An early version of this fix passed that command as literal text through --settings, which routed it through execSync's own implicit /bin/sh -c (tmux respawn-pane's bash -c "..." wrapper) before Claude Code ever saw it — POSIX double quotes don't suppress $ expansion, so those vars got expanded prematurely against the server process's own environment (unset there), producing malformed JSON that printed as literal error text in the statusline.

Fixed by writing the exporter as a real, shared script file (ensureStatusLineExporterScript, marker-versioned so stale copies self-heal) and passing only its bare path via --settings — a path has no shell metacharacters for any intermediate shell layer to mangle.

Test plan

• npm test (full CI gate) green throughout
• New unit tests: test/hooks-config.test.ts (resolveStatusLineCliCommand, findEffectiveUserStatusLineCommand), test/statusline-cli-flag.test.ts (real-shell-execution based, not hand-rolled unescaping)
• Verified live against a real Claude CLI on an isolated tmux socket (outside the app, own statusline shown untouched; inside the app, telemetry flows)
• Verified via direct execSync reproduction of the exact nested shell wrapping createSession/respawnPane use, with an arg-echoing stand-in for claude, before trusting the fix
• Confirmed the background telemetry POST never blocks statusline rendering (timed against an unreachable endpoint: ~4ms)
• Deployed to my own production instance; confirmed both in-app and outside-app behavior, including a remote SSH session (unaffected either way — remote sessions were never in scope for this injection)