feat: deduplicate model event inputs and call messages into shared pools

[rasmusfaber]

This PR contains:

• New features
• Changes to dev-tools e.g. CI config / github tooling
• Docs
• Bug fixes
• Code refactor

What is the current behavior? (You can also link to an open issue here)

Every ModelEvent.input stores the full list of ChatMessage objects, even though most messages repeat across turns in an agentic loop. Similarly, ModelCall.request stores the full provider wire-format messages. For long agent runs, this causes significant log file bloat — the same system prompt and conversation history is stored N times for N model calls.

What is the new behavior?

Message pool deduplication: Repeated messages are stored once in EvalSample.message_pool (a list of ChatMessage) and EvalSample.call_pool (a list of JSON values). ModelEvent.input is replaced by input_refs — range-encoded index references (list[list[int]], each [start, end)) into the pool. Similarly, ModelCall.request messages are replaced by call_refs + call_key.

On read, pools are transparently resolved back to full inputs, so downstream consumers see no change.

Key changes:

• New src/inspect_ai/log/_pool.py module with all pool condensing/resolving logic
• _condense.py orchestrates attachment condensation + pool dedup via _pool.py
• Schema version bumped to 3 (backward-compatible: old readers ignore new fields)
• TypeScript viewer updated to resolve pools client-side
• repair_duplicate_message_ids() fixes legacy files where content was mutated without changing the message ID

Design decisions worth discussing

Identity-based dedup (msg.id), not content equality: Messages are deduplicated by their .id field, not by deep content comparison. This is O(1) per message vs O(n) for deep equality on large content lists. The trade-off is that mutation sites (reasoning stripping, tool model_input, trim_messages) must assign a new uuid() when they modify content. This PR adds those assignments and documents the invariant in _pool.py's module docstring. An alternative would be deep equality or content hashing, but the performance cost on large messages (especially those containing images) is prohibitive.

Range encoding for refs: Rather than storing raw index arrays ([0, 1, 2, 3, 4]), refs use half-open ranges ([[0, 5]]). This compresses well for the common agentic case where each turn's input is a contiguous prefix of the pool plus a few new messages.

No nested event recursion: Pool resolution only operates on top-level events. SubtaskEvent.events and ToolEvent.events are deprecated — modern evals record all events flat. The repair_duplicate_message_ids function (for legacy file conversion) also only processes top-level events for the same reason.

Pool exclusion when events excluded: read_eval_log_sample_async now automatically excludes message_pool/call_pool when events is in exclude_fields (pools are useless without events), and forces their inclusion when events are being read (events need pools to resolve).

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

No breaking changes for consumers. The schema change is additive — old fields remain populated when reading (pools are resolved transparently). The log format version is bumped to 3, but the reader handles both v2 and v3.

Code that directly mutates ChatMessage.content on messages that will appear in ModelEvent.input must assign a new ID afterward. All known mutation sites in the codebase have been updated.

Other information:

The _pool.py module docstring documents the identity-based dedup invariant and explicitly warns against replacing it with deep equality without understanding the performance implications.