An .ndx entry's two URL halves overflow the buffer they share

[xroche]

PT_LoadCache__Old reads an entry's URL in two halves into one line[HTS_URLMAXSIZE * 2], and passes HTS_URLMAXSIZE as the bound for both. binput writes its NUL at s[max], so a first field that fills its whole bound leaves the second one writing line[2048], one byte past the array. ASan reports a stack-buffer-overflow on a crafted .ndx; the fix bounds the second call by what the first left.

Only the legacy .ndx reader is affected, and only a hand-made or corrupt index gets a 1024-character first field, since anything HTTrack wrote is shorter. Found while reviewing #743, which was looking at the strcpy calls in the same function.

Test 92 crafts that index and converts it. Note where its teeth are: a one-byte stack write does not reliably fault, so on an ordinary build the test mostly proves the parse still works. The sanitizer leg is what turns a regression into a hard failure, the same bargain 01_zlib-cache-corrupt already makes.

Separately, and not fixed here: binput returns count + 1, which over-advances when a field ends at the buffer's final NUL rather than a newline, so the next call reads one past the heap allocation. My first version of test 91 tripped it; the committed one appends a trailing entry so it exercises the field bound alone. That read overflow deserves its own change.