fix(claude): keep IDE-context envelopes out of first_message previews

[adammw]

Fixes #1238 (the previous PR did not fix the issue) for me.
I haven't evaluated if the internal/parser/claude.go changes are the best solution or if there's a way to combine the work from the previous change.

Claude Sonnet 5 explanation follows:

The VS Code extension often prepends a <ide_opened_file> or <ide_selection> wrapper directly onto a real prompt in the same user entry. PR #1252 promoted standalone envelopes to hidden system metadata, but this mixed case (envelope + real prompt in one message) falls outside that strict standalone match by design, so the raw markup stayed in first_message and the visible transcript.

Split a leading IDE-context envelope off from the rest of the message: the envelope becomes its own hidden system-metadata message (same ide_opened_file/ide_selection subtype as the standalone case), and the remaining real prompt becomes an ordinary user message. first_message and user turn counts are computed from the same firstMessageAndUserCount pass used before, so they now derive from the real prompt only.

Bumps the parser data version to 75 so existing rows re-parse.

[roborev-ci]

roborev: Combined Review (26eaed8)

Review identified one medium-severity issue affecting identity and provenance during Claude message splitting.

Medium

• Duplicate SourceUUID across split messages — internal/parser/claude.go:1110, internal/parser/claude.go:1136, internal/parser/claude.go:2156, internal/parser/claude.go:2180

  Both split messages receive the same SourceUUID. During the forced v75 reparse, source-anchored pins may move to the hidden envelope or duplicate across both rows, while Recall evidence treats duplicate source UUIDs as ambiguous and revokes provenance.

  Recommended fix: Preserve the original UUID only on the real prompt, and give the synthetic metadata row a distinct deterministic identity or no UUID. Add reparse tests covering pins and Recall evidence.

---

Reviewers: 2 done | Synthesis: codex, 10s | Total: 4m26s

[roborev-ci]

roborev: Combined Review (15dbd40)

Code review found two medium-severity correctness issues; no security concerns were identified.

Medium

• internal/db/recall_evidence_window_test.go:247 — The test inserts an envelope before otherwise unchanged messages, but the actual v74→v75 reparse changes the original row from <ide…> prompt to prompt. Because recall reconciliation recomputes the content digest, evidence spanning that row will still lose provenance_ok despite the distinct UUID.

  • Fix: Test the actual combined-to-split transformation and add narrowly scoped digest migration/normalization for the IDE-envelope rewrite, or explicitly treat revocation as expected.

• internal/db/orphaned.go:578 — Ordinal fallback also applies when a non-empty source UUID is missing or ambiguous in the rebuilt database. Since reparsing can shift or remove rows, this may silently move a pin to an unrelated message at the former ordinal.

  • Fix: Use ordinal fallback only when the source row has an empty UUID; otherwise drop unresolved pins or validate them using stable content identity.

---

Reviewers: 2 done | Synthesis: codex, 9s | Total: 6m43s

[roborev-ci]

roborev: Combined Review (58dabd8)

Code changes are generally sound, but one medium-severity pin-remapping issue should be fixed.

Medium

• internal/db/orphaned.go:1220 — The ordinal fallback runs when a nonempty source_uuid resolves to zero or multiple destination rows. If the original source message disappeared and another message now occupies that ordinal, the pin can silently attach to unrelated content.

  Fix: Use ordinal fallback only for legacy NULL/empty UUIDs. For duplicate UUIDs, require the ordinal candidate to have the same UUID; otherwise drop the pin. Add coverage for a missing UUID with a reused ordinal.

---

Reviewers: 2 done | Synthesis: codex, 9s | Total: 5m34s

[roborev-ci]

roborev: Combined Review (5193f4a)

Medium-severity correctness issue found in UUID-based metadata remapping.

Medium

• internal/db/orphaned.go:1208 — UUID remapping verifies uniqueness only in the destination. If the old session contains duplicate source_uuid values but only one survives re-parsing, a pin on the removed duplicate may be incorrectly transferred to the surviving message instead of being dropped. Require the UUID to be unique in both old_db.messages and main.messages; otherwise use the guarded ordinal fallback.

---

Reviewers: 2 done | Synthesis: codex, 9s | Total: 3m21s

[roborev-ci]

roborev: Combined Review (dbe4eba)

Code changes are generally sound, but one medium-severity parser preprocessing issue remains.

Medium

• internal/parser/claude.go:1117, internal/parser/claude.go:2172 — The IDE envelope is split after preprocessClaudeUserText runs, causing the revealed remainder to bypass command and system-reminder preprocessing. For example, <command-name>/clear</command-name> after an IDE envelope may be stored as raw XML and incorrectly become first_message instead of normalizing to /clear and being excluded from previews.

  Fix: Split the IDE envelope before preprocessing, or preprocess the remainder and honor its skip result in both extraction paths.

---

Reviewers: 2 done | Synthesis: codex, 8s | Total: 5m44s

[roborev-ci]

roborev: Combined Review (26c1417)

Review identified two medium-severity correctness issues in migration reconciliation and pin remapping.

Medium

• internal/db/recall_evidence_window_test.go:249 — The new Recall test inserts an envelope before an unchanged prompt, but the real migration changes the prompt from <ide_…>…</ide_…> prompt to prompt. Because Recall’s canonical digest includes message content, reconciliation detects a mismatch and revokes provenance for evidence anchored to the affected prompt despite its stable UUID.

  • Fix: Test the actual combined-to-split transformation and add migration-aware digest reconciliation for removal of a recognized leading IDE envelope.

• internal/db/orphaned.go:1235 — The duplicate-UUID ordinal fallback can misattach a pin after ordinal shifts. If messages A and B share a UUID, A at ordinal 1 is pinned, and reparsing removes A so B shifts from ordinal 2 to 1, the guard incorrectly accepts B because its UUID and new ordinal match.

  • Fix: For duplicate UUIDs, require stronger identity—such as matching content and role with unchanged multiplicity—before using the ordinal fallback; otherwise drop the pin.

---

Reviewers: 2 done | Synthesis: codex, 12s | Total: 5m4s

[roborev-ci]

roborev: Combined Review (af011ba)

Code is generally sound, but one medium-severity pin-mapping issue should be fixed before merging.

Medium

• internal/db/orphaned.go:1238 — UUID-less pins still fall back unconditionally by ordinal. After an IDE-envelope split, the old combined prompt’s ordinal belongs to the hidden envelope, so the pin can silently attach to metadata instead of the prompt.
  • Fix: Require matching role/content identity for UUID-less ordinal fallback, explicitly map the split shape to the following prompt, or drop the pin when identity cannot be established.

---

Reviewers: 2 done | Synthesis: codex, 8s | Total: 4m23s

[roborev-ci]

roborev: Combined Review (ef49dd6)

Pin restoration is mostly hardened, but one medium-severity duplication bug remains for orphaned sessions.

Medium

• internal/db/orphaned.go:1194 — copyPinnedMessagesForIDs copies pins before hardened restoration and joins on source_uuid without requiring uniqueness. A pinned message with a duplicated UUID can therefore attach its pin to every matching orphaned message, and the later INSERT OR IGNORE does not remove the incorrect pins. Data-version 80’s full resync may duplicate pins in orphaned sessions.
  • Suggested fix: Apply the same uniqueness and guarded fallback rules in copyPinnedMessagesForIDs, or copy orphan pins only by unchanged ordinals. Add a regression test covering an orphaned session with duplicate UUIDs.

---

Reviewers: 2 done | Synthesis: codex, 10s | Total: 3m42s