Edits were applied back-to-front by start offset with no overlap handling. A whole-pattern deletion (from the 3-argument `#set!` filter) can contain a `lua-match` or `gsub` replacement inside the same pattern. The inner replacement applied first and changed the content length, invalidating the outer deletion end offset and eating bytes of the following pattern. In update-queries.py this produced invalid query syntax, failing validation and silently falling back to older query commits. Edits nested inside another edit are now dropped (the outer edit wins), duplicates are applied once, and partially-overlapping edits raise `ValueError`, since no ordering is correct for them. Testing Done: Added `apply_edits()` tests for nested, duplicate, and partially- overlapping edits. Ran all reviewboard/treesitter tests.