fix(statusline): write statusLine.type so settings.json stays valid

[nikhilmeenaa]

The installer wired the statusline by writing the two settings keys independently, which left settings.json in a state Claude Code's schema rejects — breaking startup with a "Settings Error":

• install wrote statusLine.command but never statusLine.type, so Claude reported statusLine.type: Invalid value. Expected "command".
• clear/uninstall deleted command but left { type: "command" }, so Claude reported statusLine.command: Expected string, received undefined.

Because selfHealStatusline runs on every activation, the broken block was rewritten on every session, so the error recurred even after a manual fix.

Introduce writeStatuslineCommand() which manages the block atomically: a non-empty command writes { type: "command", command } (type first so disk is never momentarily invalid); an empty command removes the whole statusLine object (an empty {} fails the same "type required" check). Wire it into install, clearTapFromOtherScopes, and uninstall.

Add a regression test asserting statusLine.type is written on install, and update the clear test to expect whole-object removal.

What & why

Closes #

Type of change

• Bug fix (no API change)
• New feature (user-visible behaviour)
• Refactor / internal (no behaviour change)
• Docs only
• Build / tooling / CI

Checklist

• npm run check (Biome) passes
• npm run typecheck passes
• npm test passes; new/changed source has co-located __tests__ coverage
• npm run build succeeds
• npm run size is within budget (note any intentional budget change)
• No new runtime network calls (100% local, zero telemetry is a hard promise)
• No new runtime dependency without justifying its shipped cost
• CSP/nonce respected for any new webview script or inline style
• Module boundaries respected (src/core no vscode; webview/ no Node/vscode)

Testing notes