fix(pi): parse OMP title-before-session logs

[timseriakov]

Summary

• accept Pi/OhMyPi JSONL logs where a title metadata record appears before the session header
• keep parsing scoped to parsePiSessionFile() so scanning/detail/rescan behavior stays unchanged
• use a preceding title record only when the session header has no title

Why this happened

The original Pi/OhMyPi parser assumed every session JSONL starts with a session record on the first line. That matched the Pi logs I tested first.

Oh My Pi changed its session log stream to emit title metadata as its own JSONL record before the session header, for example:

{"type":"title","v":1,"title":"brief-improve","source":"user","updatedAt":"..."}
{"type":"session","version":3,"id":"...","timestamp":"...","cwd":"..."}

So the file is still a valid session log, but line 1 is no longer the session header. Codbash treated that first title record as an invalid header and returned null, silently dropping the whole session from scans. Locally this matched the missing-session symptom: Pi/OhMyPi counts went from the old undercount to pi count: 555, ohmy: 431 after parsing the delayed session header.

Fix

• scan the first 50 lines for the first { type: 'session', id } record instead of requiring it at line 1
• start message parsing after the actual session header
• if the session header has no title, reuse the preceding title metadata record
• leave unrelated scan/detail/rescan code untouched

Validation

• node --check src/data.js
• node --test test/pi-session.test.js → 14 pass, 0 fail
• local real-data scan after fix: pi count: 555, ohmy: 431

[timseriakov]

@vakovalskii bro, mr plz

[vakovalskii]

Thanks for the thorough writeup and the repro — the title-before-session case is a real gap. The fix is nicely scoped to parsePiSessionFile(), keeps us dependency-free, and the added test covers exactly the new layout. Diff applies cleanly on current main and the pi-session suite passes. One optional follow-up (not blocking): loadPiDetail() still assumes the header is on line 1 — it works today because it filters on type === 'message', but reusing the same header detection there would be nice for consistency. Merging — thanks for the contribution!