fix(sync): stop SQLite-backed containers from re-syncing on their own -shm writes

[dqtz5vpvj9-create]

Opening a WAL-mode SQLite database as a reader rewrites its -shm index. Several providers treated that rewrite as a source change: they resolved a bare -shm event to the whole container, folded the -shm mtime into the container fingerprint, or both, while each of them opens its own read connection during a scan. Together those made each scan schedule the next. On one archive the ZCode container had not changed for half an hour while its 22 sessions were rewritten every five seconds, and the usage-cache backfill and /api/v1/usage/summary failed continuously with "source archive changed during rollup build" because the archive never held still long enough.

Every SQLite-backed provider that opens its own read connection now ignores bare -shm events and leaves the -shm mtime out of its fingerprint:

• The db-backed containers (Forge, Piebald, Warp, Goose, ZCode) through the shared dbPathForEvent, plus the ZCode fingerprint.
• Zed and Shelley through the shared container classifier, the same flag Omnigent already passed.
• Kiro and Devin through their own event mapping.
• The shared journal suffix list is now main file plus -wal, so Omnigent and Cursor IDE use it instead of private copies.

Real changes always land in the main file or its -wal sibling, and every path still honors those. Existing tests that used a -shm event as an example database sibling now use -wal.

Two limits remain. The first read-only open after an agent closes its database cleanly re-creates an empty -wal, so a provider whose fingerprint reads the -wal mtime re-parses its container once per app close. That is one bounded pass, not a loop; the OpenCode provider already guards it by checking whether the WAL has frames, and the same check could be extended later. Stored ZCode mtimes from older builds included the -shm mtime, so the first scan after upgrading rewrites the ZCode archive once.

Reviewers should look at dbPathForEvent in internal/parser/db_backed_provider.go, zcodeSessionFileMtime in internal/parser/zcode.go, and sqliteDBJournalSuffixes in internal/parser/zed_provider.go.

Closes #1583

🤖 Generated with Claude Code

https://claude.ai/code/session_01PBqd7h5vuXFZehmrZATaNu

^{generated by a clanker}

[roborev-ci]

roborev: Combined Review (13d78a6)

No issues found.

---

Reviewers: 2 done | Synthesis: codex | Total: 1m54s

[roborev-ci]

roborev: Combined Review (64c51bb)

Verdict: Medium-severity planning issue remains; otherwise no significant concerns were found.

• Medium — internal/parser/db_backed_provider.go:590-599 and shared SQLite classifier
  Ignored -shm paths can still become fallback work in PlanChangedPathsContext: the provider claims the path but returns no exact sources, causing the planner to rediscover every session and potentially trigger full resyncs for remote/delta imports. Mark -shm paths as proven non-data via ChangedPathRelevance, or distinguish intentional no-ops from unclassified failures.

---

Reviewers: 2 done | Synthesis: codex, 7s | Total: 7m4s

[roborev-ci]

roborev: Combined Review (1b3b28c)

Verdict: One medium-severity issue remains; otherwise, no security or privilege concerns were identified.

Medium

• internal/parser/db_backed_provider.go:590-599 and equivalent classifiers in devin_provider.go, kiro_provider.go, Zed, and Shelley: Ignored -shm events return no sources, causing PlanChangedPathsContext to fall back to full provider discovery for providers without ChangedPathRelevance. Remote delta syncs may therefore reprocess every session in the container. Mark recognized -shm paths as ChangedPathNonData, or distinguish intentionally ignored sidecars from uncertain classifications.

---

Reviewers: 2 done | Synthesis: codex, 7s | Total: 6m27s