fix(parser): tolerate string message content; isolate per-file parse failures (#441)

[iamtoruk]

Fixes #441. Likely also fixes #425 (previous-day-always-0) for the throwing-file cause.

Root cause (as diagnosed by @jacobk — excellent report)

Some agents write a message's content as a string instead of an array of content blocks. Parsers did (msg.content ?? []).filter(...); ?? [] only guards null/undefined, so a string reaches .filter → TypeError. Because the 365-day daily-cache backfill swallows parse errors silently, one malformed session wiped the entire menubar trend/history (only "today" remained).

Fix — two layers

1. Correctness — stop the crash at the source
New src/content-utils.ts normalizeContentBlocks(content): array → returned by reference (no copy on the happy path; also drops null/undefined elements so the same crash can't recur one level down), string → [{type:'text', text}], anything else → []. Applied at every (content ?? []).filter/.some site: pi.ts, codex.ts, droid.ts, cursor-agent.ts, and the Claude path in parser.ts.

2. Resilience — one bad file must not disable the whole feature

• parseProviderSources now skips a file that fails to parse (warn once per provider) instead of re-throwing and aborting the backfill. The stale cache entry was already cleared, so the file is cleanly excluded; the rest of the backfill completes.
• hydrateCache now surfaces backfill failures on stderr instead of silently returning an empty cache.

Why both layers

Layer 1 fixes the known Pi crash. Layer 2 ensures any future schema drift in any provider degrades to "skip that one file," not "no history at all."

Validation

• Multi-agent review (correctness + adversarial). The adversarial pass found that arrays containing null elements would still crash one level down — fixed by sanitizing array elements in the helper (added a regression test).
• New tests: content-utils.test.ts (array/string/null/undefined/null-element/same-reference) + a Pi string-content regression test.
• Full suite: 1057 tests pass. tsc --noEmit clean.

Known follow-ups (not blocking, noted for transparency)

• A permanently-unparseable file is re-read every refresh (no negative-result cache) — bounded per file, not compounding.
• The per-provider warn shows only the first offending path; many failures of one provider surface as one line.