Compaction can lose recoverable tool state after function output truncation

Summary

When a large tool/function result is truncated and the thread then compacts, the continuation can lose access to data that remains present elsewhere in the persisted rollout. This can cause it to restart work or incorrectly report that records are missing.

Observed behavior

• A function call contained a complete generated command in its persisted arguments.
• Its function output was persisted with:

Warning: truncated output (original token count: 26790) ... middle omitted ...

• Compaction followed.
• The continuation saw the shortened user/history context, concluded that part of the input was missing, and returned an error.
• The complete function-call arguments were still recoverable from the rollout, but the compacted model context did not retain a durable reference to that record.

This matches the current compaction implementation: rebuilt history carries selected user messages plus a generated summary, while full tool call/result state is not retained.

Expected behavior

After compaction, the continuation should have a reliable recovery path for persisted tool state. Possible approaches:

1. Preserve compact references to persisted function-call/result IDs and allow retrieval;
2. Include an explicit summary entry naming truncated-but-recoverable artifacts;
3. Fail before compaction with a clear boundary if required tool state cannot be represented.

The key requirement is that a completed, persisted function call should not become effectively invisible to the continuation without a clear signal.