Bug-Only Diff Review (Zero Style Comments)

Review this diff for bugs and ONLY bugs. Style, naming, formatting, architecture opinions, and "consider using X" suggestions are all out of scope — assume a separate reviewer handles those. A finding qualifies as a bug only if you can name the concrete input, state, or sequence of events under which the code does the wrong thing. "This looks fragile" does not qualify. "This throws when the list is empty, and the caller at line 12 passes the unfiltered query result which can be empty" qualifies. Hunt specifically for: - Logic inverted or off by one at boundaries (>, >=, first/last element, empty input) - New code paths that skip cleanup, unlock, rollback, or event emission that the old code performed - Error handling that swallows or misclassifies failures introduced by this diff - Nullability: values that can be null/undefined reaching code that assumes otherwise - Concurrency: shared state touched without the synchronization the surrounding code uses - Contract drift: the diff changes behavior that callers outside the diff visibly depend on For each finding output: 1. **Trigger** — the exact input/state/sequence that causes the failure (one or two sentences) 2. **Location** — the diff line(s), quoted 3. **Effect** — what the user or system observes when it fires 4. **Confidence** — CERTAIN (provable from the diff) or SUSPECTED (needs code outside the diff to confirm; say exactly which file/function to check) 5. **Fix** — minimal corrected code If you find no bugs, output exactly: "No defects found in this diff." followed by the two places you looked hardest and why they turned out fine. Do not manufacture findings to seem thorough. Context (what this change is supposed to do): {{change_description}} ```diff {{diff}} ```