Custom statusLine command still silently falls back to default in 2.1.215 (regression since 2.1.53, see #28526)

Follow-up to #28526, which is locked and can no longer receive comments.

Meta note: This bug was investigated and identified by Claude Code itself, while running as my coding assistant and helping me debug why my own statusLine configuration wasn't showing up. It dug through its own settings/config loading logic, ruled out every documented cause, and only then found (via web search) that this is a known, previously-reported — and apparently unresolved — regression in itself. Reporting on its own behalf, essentially.

Still broken in 2.1.215 (macOS, Darwin 25.5.0, tested both in iTerm2 directly and in the VS Code integrated terminal).

Confirmed this isn't a config/script issue on our end:

• settings.json matches the documented schema exactly (statusLine.type: "command", statusLine.command: "...")
• The referenced script runs correctly and produces valid output when invoked manually with the exact same invocation Claude Code uses (sh -c "<command>")
• Workspace trust is accepted for the directory (hasTrustDialogAccepted: true in ~/.claude.json)
• disableAllHooks is not set
• Switching renderer mode (/tui default vs /tui fullscreen) has no effect

Would also suggest: since this fails completely silently (no error, no log, just silent fallback to the default line), it would save a lot of debugging time if Claude Code surfaced a warning somewhere (e.g. in /status, or claude --debug output) when a configured statusLine command doesn't render — right now there's no way to tell "not configured" apart from "configured but broken." Given how many closed/duplicate issues exist on this exact symptom (#28526, #43826, #29383, #17020), a clear in-product signal would likely prevent a lot of repeat debugging effort for both users and future Claude Code sessions.