v11.18.0

• PaymentFlow.Evaluate and OfferCreateCrossing.Cross index a DexSnapshot once per instance and reuse the index for every later evaluation against it (#301); Cross indexed it twice per call. The internal DexWorld is split into DexIndex, the read-only accounts, lines, books, pools, MPTs, domains and credentials, cached per snapshot in a ConditionalWeakTable, and DexWorld, which keeps what belongs to one evaluation: the fee, the passes, ReachedPartialBook, and the accounts a payment creates (DexAccounts). DexSnapshot keeps its own read-only copy of each list it is given, so changing a list after building the snapshot does not change it; a null list is an empty one
• Tests: TestUDexIndex compares results through the shared index with a freshly built one over payments and offers, sequentially and concurrently, and checks that an account a payment creates does not reach the next evaluation; BenchmarkDexWorld (manual, outside the TestU filter) measures indexing and evaluation on a synthetic snapshot of 4,000 offers and 5,010 trust lines
• PaymentFlowResult.SnapshotAfter and OfferCrossingResult.SnapshotAfter are the snapshot the transaction leaves, to evaluate the next one against (#301): XRP and trust line balances after the fee, owner counts, the sender's Sequence moved on or its TicketSequence consumed, trust lines created and deleted, offers crossed or removed, the placed offer under the index Hashes.HashOfferId gives it, pool balances (and the pool's own AccountRoot, trust lines and MPTokens when the snapshot lists them), MPTokens and OutstandingAmount, and the account a successful payment creates, with the ledger after DexSnapshot.LedgerSequence as its Sequence. The placed offer's index is made from the transaction's TicketSequence, else its Sequence, else the account's. A result that is not applied returns the evaluated snapshot. Built on first read; reading it raises InvalidOperationException when an offer is placed and no sequence is known. Its DexIndex is derived from the evaluated snapshot's (DexIndexDelta, SnapshotRoll) instead of built afresh: a chain of 15 transactions over 4,000 offers and 5,010 trust lines takes 21 ms instead of 96 ms (p50)
• OfferCreateCrossing.Cross(DexSnapshot, OfferCreate, LedgerRules) reads TicketSequence
• Docs: evaluating transactions in sequence in Amounts-Guide (both languages)
• Tests: TestISnapshotRoll evaluates chains of payments and offers offline - through books, and through an AMM pool and books - and submits them to the node, comparing each step's SnapshotAfter with the state FromNodeAsync reads back: balances, owner counts, sequences, trust lines, pool balances and both books offer by offer with their qualities. TestUSnapshotRoll runs chains of payments and offers - through books and a pool, a placed offer tied mid-book and crossed, an account created, a trust line created and deleted, MPTs moved - and checks at each step that the derived index equals one built afresh, that the next result through it equals the one through a fresh index, and that the snapshot holds the result's balance, offer, trust line and pool changes; it also checks the sequence, the ticket, the created account's sequence, that a failed payment leaves no created account, a pool's listed AccountRoot, and the copied properties. SyntheticDexSnapshot uses encoded addresses, books that do not cross, and an optional pool; BenchmarkDexWorld measures the 15-transaction chain