Non-ASCII single -O drops hts-log.txt into a mangled twin directory on Windows

[xroche]

A single -O sets both path_html and path_log, so httrack -O café url sends the logs through path_log too. argv is UTF-8, so path_log holds UTF-8 bytes, but the two-file log branch in hts_main_internal() still created its directory and opened hts-log.txt/hts-err.txt through the ANSI structcheck()/fopen(). On Windows those read the bytes as the codepage and dropped the logs into a second, mangled caf<mojibake>/ directory beside the mirror. This routes that branch through the same UTF-8 wrappers #628 used for the mirror root (structcheck_utf8/FOPEN/UNLINK/fexist_utf8), so the logs land under café/ with the mirror. On a UTF-8 filesystem the wrappers resolve to the same calls, so only Windows changes.

This is the log half of #630. I left the cache half out on purpose: relocating hts-cache is a much larger, coupled change, because the cache is written through minizip's own ANSI fopen and cleaned up through an ANSI opendir, so half-converting it would split or break the cache rather than move it. That wants its own PR, and #630 should stay open for it.

Test 69 mirrors into a single non-ASCII -O and asserts the audits read hts-log.txt from that directory. Like test 64 it only bites on the Windows CI leg, where the two encodings differ; on Linux the change is a no-op and the whole suite stays green.