Changes touching this path

• bundle_impl stops visiting every manifest entry of every held-back change to answer a wants question, and this ticket's proposed fix was the wrong one: reaching the existing wanted_finalized_entries index would have moved the cost rather than removed it, because that function is the SAME O(changes times entries) walk - #1425's saving was amortising one walk across many batches, not making the walk cheaper - and it moves nothing at all on the relay /fetch path, which builds one bundle and never batches. It also cannot serve batch zero on its own terms: it has no have, so no send set and no attestations, and it is wants-scoped while bundle_impl's key lane fires for non-want entries of sending changes. The missing piece was never an index, it was a STOP RULE, so both walks got one. bundle_impl becomes two passes over one topological order, the send set unchanged and a second wants lane over held-back changes that is skipped outright when wants is absent or empty and stops as soon as every want is settled, and wanted_finalized_entries gets the same rule walked newest-first. The consequence worth naming is that held-back manifests are no longer materialized at all, which is the cost d6be741 removed from the repo open and this path was re-paying at push time; it is pinned over a saved-and-reopened repo through Manifest::is_materialized with a control that was proved to fire, since an in-memory repo defers nothing and would have made the pin vacuous. Byte-identity is differenced against one_pass_bundle, a statement-for-statement transcription of the base walk, over ten have-and-wants shapes, because the whole claim is that this is a cost change and not a behaviour change. This ticket's 512.6 ms does not reproduce: at 436 paths and 128 changes the release cost is 7.43 ms, which extrapolates in depth to about 58 ms at the ticket's 1000, roughly nine times smaller, and three confounds compound - the debug-build suspicion #1704 raised, #1701's probe memoisation landing in between, and this half keeping its objects in memory. The shape was real and the growth was real, so the fix is worth 86.0 percent at 64 by 128 and 92.5 percent at 436 by 128 on the named half, but the number that ranked this finding was wrong and saying so is worth more than repeating it. A defect this change introduced was caught by its own review and is recorded rather than quietly fixed: ride_entry returned true on a store refusal without consulting bytes_ride, so a non-want entered settled, and a sent change naming one burned or withheld address made the settled count reach the wants count with a real want still unanswered - silently skipping the #803 recovery lane and breaking byte-identity. The fixture had no unproducible address, so the headline pin was blind to it; the fixture now carries a burned one in the send set and the defect was proved red before the fix. Four loot-perf doc sites went stale by this change and are amended here rather than left: they described the held-back walk as the cost this half watches ACCUMULATE, where it is now the cost it holds GONE - the half is not blind, since re-nesting the loops returns the reading, but a future comparison is against 126 microseconds and not the number the row was born with (#1702) 68a0bded · dbf3dbe6…

Renames are not followed. loot's tree maps a path to an address, so a rename is a delete and an add. This list is the history of the name, not of the bytes.