[REPPL]

What this changes

A view read each reservation tip in three git processes: its name (for-each-ref), its size (cat-file -s) and its body (cat-file commit). A drain views on every move, so it paid three per reservation per move. The view now reads the ordinary tips, commits within the object bound, in three processes however many there are:

1. one for-each-ref listing the reservation refs with their objects and types;
2. one cat-file --batch-check for the commits' sizes;
3. one cat-file --batch for their bodies.

Each runs through claim's storedGit (history as stored, replace refs off) and is capped. Nothing is kept beyond the call: every ref is resolved to its commit afresh each time.

A trust boundary

The tips come from origin, written by whoever can push to the reservation namespace, so the batch is read as untrusted and is a shortcut only.

• What the batch accepts: a body is taken from it only under the exact name and size the check read. A tip it does not answer that way is read on its own, exactly as before, with every bound and refusal that read applies. That covers a missing object, a non-commit, a tag, an object past the bound, and an answer out of shape.
• Bad answers stay contained: the cut stops at the first answer it cannot read, so one bad tip never shifts another's body under its name, and a missing object costs only itself.
• Ref names: only refs the view has already vetted reach the batch, matched exactly.
• Memory: one batch reads at most 1 MiB of commit bodies, about 126 tips at the object bound. A tip past that is read on its own, so a view's memory stays flat however many reservation refs a writer pushes.

A bug the review caught. Round one of review found that the batch handed the parser the bytes as git sent them, while storedGit trims trailing whitespace. A writer could push a reservation whose message was the message cap plus its newline, or ended in blanks. The view would then read it as unreadable, with no holder or footprint, while every act read it as a live hold. The batch now trims exactly as storedGit does (the second commit).

Effect

One drain test in internal/core/implement/loop:

	git processes
Before #1099	1,107
After #1099	1,019
After this change	830

A view of four tips now runs 2 cat-file processes instead of 8.

Evidence

• Parser: TestTheCommitBatchIsCutOnlyWhereItReadsAsAsked cuts crafted answers: a missing object mid-batch, a wrong size or type, an answer out of order, a short read, a body without its newline, and bytes past the end.
• Equivalence: TestABatchedViewReadsEveryTipAsItsOwnReadWould and TestABatchedReadAgreesWithItsOwnReadAtEveryBound read each tip both ways and hold them equal. The tips include an oversized commit between two readable ones; messages either side of the message cap, raw and trimmed; one ending in blanks; commits of exactly the object bound and one past it; two refs on one commit; a blob; and a tag. They also assert which tips the batch itself answered, so a silent fallback cannot pass. The second fails without the trim, and also with a trim of newlines alone.
• Budget: TestATipPastTheBatchBudgetIsReadOnItsOwn holds tips past the budget to their own read. It fails if the budget is ignored.
• Process count: TestAViewReadsItsTipsInAFixedNumberOfProcesses pins the view's process count.
• Suites: claim, peers, loop and CLI pass.
• Preflight: make preflight passed on this commit (receipt minted).
• Review: Opus and Sonnet security reviewers on frozen copies, briefed as parsing at a trust boundary. Round one: STOP on the trim divergence, which each confirmed with a probe. Round two: both LAND, with their probes re-run, and a budget probe of 140 and 330 tips, every tip matching its own read.

Resolves: iss-2610180545134593

Assisted-by: Claude:claude-opus-5-5

[REPPL]

Merge-group times after this change and #1099 (2026-10-18):

Run	ubuntu leg	its race step	macOS leg	its race pass
#1095 (before both)	18.3 min	—	43.9 min	41.9 min
#1099	23.3 min	20.8 min	49.4 min	47.4 min
#1100 (this)	23.1 min	20.6 min	44.8 min	42.4 min

The two changes do not show on CI. The ubuntu race step is at the top of its earlier 14 to 20.6 minutes, its package times sum to about the same CPU as before (4,243 and 4,293 seconds against 4,254), and the loop package's race time is inside its earlier range. The cut in git processes (one drain test, 1,107 to 830) is real where it was measured, but smaller than the difference between runners. The resolved record's grounds named exactly this as what would show them wrong, so the record now says so.

The macOS leg is above 42 minutes on both runs, and #1099's came within 0.6 minutes of the 50-minute warning, so its headroom is captured as iss-2610181711260494 (minor), with the nine-run spread of 35.2 to 49.4 minutes.