Desktop app silently ignores ~/.claude/settings.json when the file has a UTF-8 BOM (JSON.parse SyntaxError, warn-level log only)

## Summary

If `~/.claude/settings.json` is saved as **UTF-8 with a BOM**, the desktop app fails to parse it and falls back to defaults for **every** user setting — silently. The only trace is a single `warn` line per read in `main.log`. Nothing surfaces in the UI, and `/config` keeps showing (and writing) values as if the file were being honoured.

What makes this particularly hard to notice is the asymmetry: **the bundled CLI tolerates the BOM and reads the same file fine**, so hooks and permissions from `settings.json` keep working normally. Only the app-side settings quietly stop applying.

On Windows a BOM is easy to introduce by accident — PowerShell 5.1's `Out-File` and `Set-Content -Encoding utf8` both write UTF-8 **with** BOM, so any script or one-liner that edits `settings.json` corrupts it from the app's point of view.

## Environment

- Claude Desktop app on Windows 11 Pro (10.0.26200)
- Bundled Claude Code 2.1.219
- `~/.claude/settings.json` written at some point by a PowerShell script

## Evidence

The file, as it was:

```
$ head -c 16 ~/.claude/settings.json | xxd
00000000: efbb bf7b 0d0a 2020 2020 2265 6e61 626c ...{.. "enabl
```

`JSON.parse` rejects the leading U+FEFF, and the app logs:

```
2026-07-17 02:51:35 [warn] [SettingsIo] Failed to read C:\Users\owner\.claude\settings.json (SyntaxError)
```

This repeated on **every** settings read for nine days without any user-visible symptom — 514 occurrences in a single rotated log file:

```
$ grep -c "SettingsIo] Failed to read" main2.log
514
```

Meanwhile the CLI parsed the very same file correctly throughout: the `SessionStart` hook defined only in that `settings.json` executed normally on every session start.

Stripping the three leading bytes fixed it, with no other change to the file:

```
before: efbbbf size 3913
after : 7b0d0a size 3910
```

## Impact

Every app-side setting silently reverts to its default. In our case `"remoteControlAtStartup": true` had been set for weeks and was never actually applied — Remote Control simply did not arm at startup, and there was no way to tell from the UI that the setting was being ignored. `theme`, `inputNeededNotifEnabled` and `agentPushNotifEnabled` were equally inert.

Because `/config` reads and writes through the same broken path, toggling a setting appears to work and then has no effect, which sends users looking for a bug in the feature rather than in settings loading.

## Reproduction

1. `powershell -c "Get-Content ~/.claude/settings.json | Out-File ~/.claude/settings.json -Encoding utf8"` (PS 5.1 — adds a BOM)
2. Restart the app, or just switch session focus.
3. `main.log` shows `[SettingsIo] Failed to read … (SyntaxError)`; all app-side settings are now at their defaults, with no UI indication.

## Expected

- Strip a leading BOM before `JSON.parse` in `SettingsIo` (the CLI already does the equivalent — the two readers should agree on what a valid settings file is).
- If a settings file cannot be parsed, surface it to the user (a banner, or an entry in `/doctor`) instead of a single `warn` line in a log the user has no reason to open. Silently running on defaults is the worst outcome here.

Start by locating the desktop app's SettingsIo reader and compare it with the bundled CLI settings reader, using the provided UTF-8 BOM reproduction as the first check. Verify that settings.json values are applied after BOM handling, then inspect the /config or other user-facing diagnostics path for a visible parse failure instead of only the main.log warning.

Written by the indexing model from the issue text.