v2.38.7 — read-heavy session checkpoint coverage

gsd-plugin v2.38.7

Plugin-only patch. Closes a real checkpoint gap during read-heavy research sessions.

What was broken

v2.38.5's PostToolUse periodic checkpoint used matcher `Bash|Edit|Write|MultiEdit|NotebookEdit` — file-mutating tools only. A research-phase session this morning hit a usage cap with the last checkpoint written 18 minutes earlier; those 18 minutes were almost entirely `Read`, `Grep`, `Glob`, `WebFetch` calls (no file mutations). PostToolUse never fired → no checkpoint → 18 minutes of work state vulnerable to loss.

What's in v2.38.7

Fixed:

• PostToolUse matcher broadened to also include `Read|Grep|Glob|WebFetch|WebSearch`. Combined with the existing 60s mtime throttle, write rate stays bounded ≤1/min regardless of how often the hook fires. Smoke-tested under burst load: 5 rapid reads → 1 write.
• Net guarantee: `HANDOFF.json` is at most ~60s stale during an active session, regardless of whether the work is read-heavy or write-heavy.

Changed:

• README "What changed from upstream GSD" expanded from a single 6-row table into four grouped tables (Install + runtime architecture, Session continuity, Drift resilience, Plugin-environment robustness). Surfaces the v1.1, v1.2, and v2.38.x improvements that previously weren't documented as user-facing differences vs upstream.

Token cost: zero

Verified in CC source (`utils/messages.ts:4099-4115`): PostToolUse hook output is never injected into the model's context — only `SessionStart` and `UserPromptSubmit` produce systemReminder messages. The hook fires more often now, but it costs only wall-clock (~5-10ms per throttled fire) and disk I/O (~1KB per actual write, ≤1/min). No conversation tokens consumed.

Based on

Upstream GSD 1.38.3.