insertAllAfter

Append values as a chain starting immediately after after, minting one RgaOp.Insert per element on behalf of replica.

The bulk sibling of insertAfter, and indistinguishable from calling it in a loop: the same ids, the same after links, the same Lamport clock, the same op-set. What differs is the cost. insertAfter rebuilds ops and insertsById on every call, so appending k elements to an N-op log is k copies of N — Θ(k·N). This pays one ops + newOps and one cache build for the whole run, so it is Θ(N + k).

That is the amortisation WarpLogRecordExporter needs to stop paying a Θ(N) append per log record (#2194), and it needs no persistent data structure and no new dependency on this deliberately dependency-free module. It does not remove the Θ(N) term — one ops copy per run remains, which is #2193's Phase 3A.

When this really is an append — after is the last element of the full sequence — and this instance is carrying a threaded order, that order is extended instead of being recomputed (#2193's Phase 3B). Any other after, or an instance not carrying one, passes nothing on and the next read rebuilds once.

"Carrying a threaded order" is narrower than "has a materialized sequence": an instance whose lazy was forced by a plain read does not qualify today, so an append after a read threads nothing even though the guard's premise holds. Tracked by #2225; see sequence.

An empty values returns this — the same instance, not a copy.