v0.9.14: paged child reads with size/truncated/line_count in every response — kill size-blind chunking

[Hmbown]

Why this matters

The 638k-token read death was size-blind chunking: the model had no way to know the file was 542KB before paging into it. kimi-code's answer (refs/kimicode/kimi-code packages/agent-core-v2/src/workspace/workspaceFs/fs.ts:105-124) makes every read self-describing: offset+length (default window 1 MiB, hard max 10 MiB) and a response that ALWAYS carries size, truncated, line_count. The size field is the subtle killer feature — the model learns the true file size up front and stops chunk-blind paging.

Design

1. The child-facing read tool gains offset/length paging with a 1 MiB default window and 10 MiB hard max.
2. Every read response carries size, truncated, line_count (schema'd, kimi pattern).
3. Ship ripgrep (runRg.ts in kimi's tree is the reference) as a first-class sibling tool so grep-before-read is mechanical, not prompted.

Acceptance criteria

• Reading a >10 MiB file without paging params returns page 1 + size + truncated: true, never the whole file
• A test proves the child's context growth from a paged read is bounded by the window
• grep tool available in the child surface; a test shows a grep-then-windowed-read flow

Related

• v0.9.14: a worker's reserved report turn is spent by its own descendants — budget death returns nothing at all #6277, v0.9.14: write-claim contention forbids N workers writing disjoint files under one shared root — the natural fan-out pattern is impossible #6278, and the capture-time caps issue (complementary: caps bound the worst case, paging makes the model not want it)