feat: add supersedeReads strategy to prune stale read outputs

[sudorest]

Summary

Adds a new automatic pruning strategy — supersedeReads — that prunes stale read tool outputs when the same file has been subsequently written or edited successfully. This is the natural complement to the existing supersedeWrites strategy.

Problem

In a typical coding session, the model frequently reads a file, then edits or writes to it. After a successful write/edit, the original read output is stale — the file contents have changed. These outdated read outputs waste context tokens and can cause the model to reference old file contents, leading to confusion and hallucinations.

Read outputs are often large (entire file contents), so pruning them yields significant token savings.

Solution

The new supersedeReads strategy:

• Tracks all read tool calls and all successful write/edit tool calls by file path
• Prunes read outputs where a subsequent successful write/edit targets the same file
• Ignores errored writes — if a write failed, the file wasn't actually changed, so the read is still valid
• Enabled by default (consistent with supersedeWrites)
• Respects all existing guards: protectedFilePatterns, manualMode, automaticStrategies, turn protection

Changes

File	Change
lib/strategies/supersede-reads.ts	New strategy implementation
lib/strategies/index.ts	Export the new strategy
lib/config.ts	Add SupersedeReads interface, config keys, validation, defaults, merge logic
lib/tools/compress.ts	Wire strategy into compress tool execution
dcp.schema.json	Add supersedeReads to JSON schema for IDE autocomplete
tests/supersede-reads.test.ts	14 comprehensive tests
tests/compress.test.ts	Add supersedeReads to test config fixture

Configuration

{
    "strategies": {
        "supersedeReads": {
            "enabled": true  // default
        }
    }
}

Testing

• npm run typecheck — passes
• npm test — 30/30 tests pass (14 new + 16 existing)
• npm run format:check — passes

Test coverage

Test	What it verifies
Prunes read then write (same file)	Core happy path
Prunes read then edit (same file)	Edit also supersedes
Write before read	Chronological order matters
Different files	No cross-file pruning
Errored write	Failed writes don't supersede
Multiple reads	All stale reads pruned
Read after write	Only pre-write reads pruned
Already-pruned reads	No double-counting
Disabled config	Respects enabled: false
Manual mode	Respects automaticStrategies: false
Protected file patterns	Glob patterns honored
Multiple files independently	Per-file tracking
Empty tool list	Graceful no-op
Non-file tools	Only file tools affected

[Tarquinen]

Why should editing a file prune the read from context? that means you can't edit it again without first reading it again. You're right pruning the read when it has been overwritten by a write tool makes sense though. Also supersede writes is on its way out, that strategy doesn't work for other reasons.

I like the idea! Will review if you address the first issue.