fix(server): bound agent timeline history

[dwaxe]

Refs #2300

Bounds daemon memory used by long-running root and Codex provider-subagent histories.

• bounds parent subagent previews while retaining canonical child activity
• restores child descriptors without loading their bodies and pages child history on demand
• keeps a bounded hot root tail and pages older committed rows from a segmented disposable cache
• enforces row, batch, pending, and resident byte limits, including oversized timeline items
• fences reload, delete, and close operations across cache generations
• exposes timeline retention metrics

Provider history remains authoritative, and daemon startup clears the disposable cache fail-closed.

[greptile-apps]

Greptile Summary

This PR introduces a segmented disposable timeline cache that bounds resident root history while paging committed rows from disk.

• Adds bounded hot-tail storage, ordered durable buffering, segmented persistence, cache generation fencing, and startup invalidation.
• Integrates bounded timeline reads and metrics into agent management and daemon diagnostics.
• Extends client and server handling for bounded projected-history failures and adds regression coverage for paging, eviction, lifecycle, and race behavior.

Confidence Score: 5/5

The PR appears safe to merge because no blocking failure remains.

No blocking failure remains.

Important Files Changed

Filename	Overview
packages/server/src/server/agent/bounded-agent-timeline-runtime.ts	Coordinates bounded hot storage with ordered durable persistence and generation-aware lifecycle operations.
packages/server/src/server/agent/segmented-file-agent-timeline-store.ts	Implements segmented disk-backed timeline persistence and paged committed-row retrieval.
packages/server/src/server/agent/agent-manager.ts	Integrates bounded timeline storage, paging, lifecycle fencing, and provider-history behavior into agent management.
packages/server/src/server/bootstrap.ts	Wires disposable timeline cache initialization and fail-closed startup invalidation into daemon bootstrap.
packages/server/src/server/agent/agent-manager.test.ts	Adds regression coverage for bounded timeline integration, reload behavior, failure recovery, and lifecycle cleanup.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  P[Provider history] --> N[Bound and normalize timeline items]
  N --> B[Ordered durable buffer]
  B --> D[Segmented disk store]
  N --> H[Bounded hot tail]
  D --> R[Paged historical reads]
  H --> R
  R --> C[Projected client timeline]

Loading

_{Reviews (2): Last reviewed commit: "fix(server): preserve current timeline c..." | Re-trigger Greptile}

[greptile-apps]

Tests depend on private internals

These tests cast AgentManager to expose private state, replace persistSnapshot, and use setTimeout(0) to infer reload settlement. That makes behavior-preserving refactors break the suite and makes the reload assertion sensitive to event-loop scheduling; exercise the manager through its public interface and deterministic gates instead.

Rule Used: # Code Review Pattern Reference: Slop, Tests, Feat... (source)

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[boudra]

Closing for now: this needs before/after daemon heap and RSS measurements under long-running Codex root/subagent activity, with older-history paging and reload verified. Please reopen with that evidence.

[boudra]

Please disregard the earlier invitation to reopen with evidence. This PR remains closed unless I explicitly follow up. You don't need to resubmit this PR or provide further QA evidence.

Please read the updated PR policy. For now, I'm automatically closing feature PRs so I can focus more time on bug fixes and core improvements. Focused bug-fix PRs with a clear reproduction and QA are still welcome. The previous guide already asked contributors to submit only if they were comfortable with closure, and explained that unsolicited PRs could be closed without a detailed review.

For feature ideas, please start in GitHub Discussions and share your workflow: what you're trying to do, how you do it today, and where Paseo gets in the way. If there's already a discussion about it, join in and share your use case. I'll periodically review discussions for highly requested workflows and use that feedback to shape the roadmap.

I'll periodically look through closed PRs and choose which contributions to take forward, whether solicited or unsolicited. I may reopen a PR, including one closed by mistake, or use it as a reference for my own implementation, with attribution either way.

There are hundreds of PRs alongside ongoing development. I can't commit to reviewing every submission, providing individual feedback or giving timelines.