Reading an .ndx cache walks the parser past the end of its buffer

[xroche]

binput() returns count + 1, assuming it consumed a separator. It did not when it stopped on the buffer's terminating NUL, or because the destination filled: that byte is data, and the caller's cursor ends up one past it. In PT_LoadCache__Old the cursor then sits outside the heap buffer holding the .ndx, and the next binput() call reads out of bounds. It is a read and not a write. The trigger is the walk reaching use[ndxSize], which any index that does not end in a newline reaches, so full-length URL fields are one route into it and not the only one; a field a byte under capacity that ends at EOF gets there too. Only the legacy .ndx reader is affected, and everything HTTrack writes ends in a newline, so it takes a hand-made or corrupt index. The loop's a < (use + ndxSize) guard cannot catch any of this, because the drift happens after the check.

Step over the byte only when it really is a newline. cache_brstr() had to follow, since it carried a caller-side patch for the same drift and its adr[off - 1] probe would read before the buffer now that binput() can return 0. Test 92 covers the neighbouring write overflow from #744 and appends a trailing entry on purpose, so the drifted cursor still lands inside the malloc'd buffer and 92 passes on the unfixed tree. Test 117 drives all three field bounds (1024, whatever the first URL half leaves, 200), cache_brstr's own 256, and a field that fills none of them. Two of its cases have teeth outside the sanitizer build: two URLs differing only on the 1024 bound must stay two cache keys, and a header one byte past 256 must parse like a header two bytes past. On master each loses an entry.

Closes #793