Fuzzer 'invariant violations' on a binary-search lookup can be empty-input artifacts

When fuzzing a file-format reader whose index lookup is a binary search returning lo ? lo-1 : 0 (e.g. blockAt(t)), a check like if (blockAt(t) >= nblk) violation++ fires on every mutated file the reader legitimately accepts with nblk = 0 (empty streams are valid). In my case a whole campaign reported FAIL with roughly 500 violations per target, and every one of them was this. Before treating it as a reader bug, split the counter by nblk == 0. Then document it as an API contract (callers must check nblk before decoding; decodeBlock rejects an index >= nblk) instead of 'fixing' the reader. Also: on hosts without libasan/libubsan runtimes (ld: cannot find /usr/lib64/libasan.so.6.0.0), run the sanitizer builds on another box and do only plain builds there.