fix(store): skip corrupted part_json and info_json rows instead of crashing

[Milofax]

Summary

One corrupted parts.part_json or messages.info_json row in the SQLite
archive currently takes out grep, describe, and the automatic
retrieval transform pipeline. parseJson is called directly in six
stored-row load sites inside store.ts, so a single unparseable blob
bubbles up as Failed to parse JSON: Unterminated string and kills the
entire batch load instead of skipping the bad row.

This PR adds a non-throwing parseJsonSafe<T>() companion to parseJson
in utils.ts and replaces the six unsafe call sites:

• readSessionsBatchSync: the part_json and info_json loops (this is
  the exact stack in the production crash report).
• readSessionSync: the part_json and info_json loops.
• readMessageSync: the info_json load and the inner part_json map.

A corrupted part or message row now gets skipped with a structured
logger warning that carries operation, sessionID, messageID,
partID, error, and a 120-char preview of the offending blob — the
surrounding batch load keeps going and returns the healthy rows instead
of throwing.

Reproducer

Failed to parse JSON: JSON Parse error: Unterminated string
Input: {"id": "prt_d798683da001WV5rR5cUmpKdDA", "type": "text", "text":"
  at parseJson (dist/utils.js:35:19)
  at readSessionsBatchSync (dist/store.js:3786:26)
  at readScopedSessionsSync (dist/store.js:1804:21)
  at searchByScan (dist/store-search.js:194:27)

Triggered by a lcm_grep call whose FTS path returned zero hits and
fell through to the scan path against a session that had one
on-disk-corrupted parts.part_json row.

Regression test

tests/store-transform.test.mjs gets a new test
grep scan survives a single corrupted part_json row. It:

1. Captures three valid messages.
2. Opens the SQLite db directly and UPDATE parts SET part_json = '{"id": "m2-p", "type": "text", "text": "cosmic-ray corrupt b' to mimic on-disk truncation.
3. DELETEs all three FTS tables (message_fts, summary_fts, artifact_fts) so grep is forced down the scan path — the exact code path the user crashed on.
4. Reopens the store and calls store.grep({ query: 'cosmic-ray', sessionID: 's1' }).
5. Asserts both surviving messages are returned and the corrupted one is silently dropped.

Without the fix, step 4 throws. With the fix, step 4 returns m1 and m3.

Test plan

• npm run typecheck — clean
• npm run lint — clean
• npm test — 169/169 green (was 168 before the new regression test)
• Manual smoke-test in OpenCode against a real corrupted .lcm/lcm.db — lcm_grep no longer crashes, logs the skipped row, returns the surviving hits

Notes

• parseJson itself is unchanged — structural invariants (e.g. summary_state.root_node_ids_json) still throw on corruption, which is the right behavior for places where a failure means the store is unrecoverable rather than just one row being bad.
• No schema changes, no migration needed, safe to ship in a patch release.

🤖 Generated with Claude Code

[Plutarch01]

Closing in favor of #8, which lands the same corrupted-JSON-row fix cleanly against current master without the stale conflicts and version churn in this PR.