fix(config): keep an existing refreshInterval when the version probe fails

[taehwanis]

Refs #297 (the PR that added statusLine.refreshInterval support — no separate issue is open for this)

Summary

installStatusLine captures the existing statusLine.refreshInterval before replacing the statusLine object, but only re-applies it when supportsRefreshInterval is true.

getClaudeCodeVersion() returns null — and isClaudeCodeVersionAtLeast() therefore false — in four cases that are not "unsupported version":

• claude is not on PATH
• the 5s execSync timeout elapses
• stdout does not match /^(\d+\.\d+\.\d+)/ (e.g. something is printed before the version)
• the process exits non-zero

In all four, a re-install silently removes a refreshInterval the user had set, on a Claude Code that may well support the setting. (The TUI reports all four the same way too, as "requires Claude Code >=2.1.97".)

#297 documents the intended contract as "preserve existing value on re-install", so the version gate appears to reach one case further than intended: it should gate the default, not the preservation.

Change

Only the default of 10 stays gated on supportsRefreshInterval; an existing value is written back either way.

existing value	supported	before	after
—	yes	10	10
—	no	unset	unset
5	yes	5	5
5	no	dropped	5

Only the last row changes. Nothing new is written for users who never had the key, so the concern behind the original gate — not writing an unknown key into an older Claude Code's settings.json — still holds.

Tests

The three existing tests in installStatusLine refreshInterval cover the first three rows; the fourth had no test, which is why this went unnoticed. Added it.

bun run lint is clean. bun test reports 1867 pass / 2 fail — the same 2 failures reproduce on an unmodified checkout of main on Windows (config utilities > saves through a symlinked settings file without replacing the link and global command resolution > silences child stderr on best-effort probes so failures cannot leak to the terminal). Both look environment-dependent and are unrelated to this change; the pass count goes 1866 → 1867.

Feedback I'm looking for

1. Is gating only the default the behaviour you want here? An alternative shape is to leave settings.statusLine.refreshInterval untouched rather than rebuilding the statusLine object and restoring the field.
2. Should the version probe distinguish "unsupported" from "could not determine"? They currently collapse into the same false, which also drives the TUI's "requires Claude Code >=2.1.97" message. Happy to split that into a separate issue if it is out of scope for this PR.