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

## 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

- #6277, #6278, and the capture-time caps issue (complementary: caps bound the worst case, paging makes the model not want it)

Start by locating the child-facing read tool and its tool surface; the issue names kimi-code’s packages/agent-core-v2/src/workspace/workspaceFs/fs.ts:105-124 and runRg.ts as reference points. Add tests for bounded context growth on large paged reads and a grep-then-windowed-read flow. Done means every response exposes size, truncated, and line_count, paging enforces the stated limits, and grep is available to children.

Written by the indexing model from the issue text.