Backward scans from strlen(s) - 1 walk off the front of the buffer

[xroche]

Two loops start at the last character of a string and decrement with no lower bound, so both run past the front when the string is nothing but separators.

optinclude_file() right-trims every config line with a = line + strlen(line) - 1; while (is_realspace(*a)) *(a--) = '\0';. A line of nothing but spaces in a httrackrc walks below the 256-byte stack array, reading each byte on the way down and writing a NUL over it whenever that byte happens to be whitespace. ASan reports the underflow of line directly.

url_savename()'s collision rename does the same over digits: b = tempo + strlen(tempo) - 1; while (isdigit(*b)) b--;. That one needs no empty string, only an all-digit save name, and a crawled page supplies it. Under -N "%n.%t" depth is unrestricted, so a single starting URL is enough: a page linking /a/2024.html and /b/2024.html collides both onto 2024.html, the second goes through the -<n> rename, and the scan then has nothing but digits left to walk over. Reproduced under ASan at htsname.c:1703 by way of htsparse.c and httpmirror, both from one URL and from -g with the two spelled out.

Both now go through hts_rtrimlen(), which counts down from the end and stops at the start of the string. The config-file trim also moved ahead of the emptiness test, so a blank line is skipped instead of reaching the option parser as an empty name.

The Content-Disposition trim in treathead() was a third copy of the same loop and shares the helper now, but that one is a deduplication and not a fix: a is always preceded either by the = of filename= or by a / left behind by the RFC 2616 skip loop, and neither character is in is_space, so the scan could not leave tmp.

htsname.c:1680 sits inside the block being edited here and is left alone. It belongs to the x + strlen(x) - 1 class of #781, which the stacked PR converts.

-#test=rtrim poisons the byte under the string, which is where the difference shows: neither ASan nor _FORTIFY_SOURCE sees an overrun that lands inside the same stack frame. Test 116 drives the collision rename end to end by both routes and pins both call sites at the source, because on a plain build the byte below the buffer is usually not a digit, so a reverted scan stops anyway and produces the same names. It is added to the Windows job by name, since that job iterates a fixed glob that 116_engine-* does not match and the rename is savename logic, which behaves differently there.

Closes #814