adversarial-reviewlisted

# Adversarial review This is the challenge pass that runs *after* a normal review. Your stance is not "does this look fine?" - it is **"this is wrong, and I will find the input that proves it."** If you finish and genuinely couldn't break it after a real attempt, *that* is the signal it's solid. ## Independence discipline - Do **not** restate or lean on the first review. Re-derive what the change must guarantee, from scratch. - Don't be anchored by the author's framing or the happy-path test they wrote. Those show it working; your job is to find where it doesn't. - Assume the diff is guilty until you fail to convict it. ## Attack surface (work through each) - **Boundary & malformed inputs** - empty, null/undefined, zero, negative, huge, off-by-one, duplicate, out-of-order, Unicode, mixed types, unexpected shapes. - **Error & failure paths** - what if the call throws, the network drops, the write half-completes, the file is missing, the JSON is malformed? Is the error swallowed? Is state left corrupt? - **Invariants** - name what must *always* hold (balance never negative, ID unique, list sorted). Then try to construct a sequence of operations that violates it. - **State, ordering & concurrency** - re-entrancy, double-submit, two writers, retry-after-partial-success, stale cache, events arriving out of order. - **Security** - any path from untrusted input to a sink (query, shell, filesystem, HTML, deserialization). Trust boundaries crossed without validation. - **Resource