The replay request index exists solely so that the next item in a
sequential apply loop observes the mutated payload. Both loops rebuilt it
after every successful mutation, including after the final item, whose
rebuild no successor ever reads.
insertAntigravityReasoningReplayItemsWithSchemas is worse than that: its
index parameter is a local pointer, so a rebuild is discarded the moment
the function returns. applyAntigravityReasoningReplayItems only ever
passes a single eligible item, which made every one of those rebuilds
dead work, and the caller then rebuilt the same payload again.
Rebuild only when a successor still has to read the index. Behavior is
unchanged: 800 differential rows over 400 randomized multi-turn payloads
(570 of them mutating) hash-match the previous implementation byte for
byte, under both nil and populated tool schemas.
BenchmarkApplyAntigravityReasoningReplayItems/indexed (1 MiB, 32 turns):
before ~302 ms/op 66309 allocs/op
after ~269 ms/op 62153 allocs/op
A real 24 MiB production payload (182 contents, 96 ledger items) shows
the effect the synthetic benchmark understates:
before 6723 ms/op 223381 allocs/op
after 4035 ms/op 144789 allocs/op
bb7278a1af