A best-fit substitute made the strict UTF-8 converter lossy on Windows

[xroche]

On Windows, WideCharToMultiByte substitutes a lookalike character when the target codepage lacks a code point, and does not report that substitution through lpUsedDefaultChar. U+00A5 comes out of CP932 as 0x5C, so hts_convertStringFromUTF8Strict saw no loss and handed back a path separator where the document wrote a yen sign. Both WideCharToMultiByte calls now pass WC_NO_BEST_FIT_CHARS, gated on cp_reports_default_char. That predicate already picks out the codepages needing dwFlags == 0, so it needed no change. The yen becomes the codepage's default character, usedDefault is set, and strict returns NULL.

Setting the flag is not quite enough on its own. Sizing with it reports the length of the substitute, but the converting pass still wants room for the form it replaced, so a buffer sized from the flagged pass is refused: U+00B5 sizes as 1 byte on CP932 while its best-fit takes 2. The exact-length guard then rejected a conversion that had succeeded, and hts_convertStringFromUTF8 returned NULL for ten Latin-1 code points. The buffer is now sized for the larger of the two passes and the written length is taken from the conversion. The Windows CI leg is what caught this; the numbers above are measured there, not inferred. The max() is defensive: per code point the flagged size is never larger than the best-fit size, since no codepage we know of has a default character longer than a best-fit substitute, so the fsize > bsize arm is believed unreachable and the bug fixed here is the reverse, fsize < bsize, which the flagged pass reports and the converting pass cannot fit.

The non-strict callers change too (hts_convertStringFromUTF8, hts_convertStringUTF8ToSystem, hence WinHTTrack's ANSI entry points). Approximations that used to pass through (folding full-width to half-width, or dropping an accent) now come out as '?'. This is intended, but the change is visible well beyond the dangerous cases. It also brings the Windows build to where the iconv build already stood: failing instead of approximating.

The new -#test=nobestfit self-test asserts the best-fit mappings and the two sizing lengths themselves before it tests the engine, so it cannot pass vacuously if any of them ever changes. U+00A5 alone would not have found the sizing bug: it is one byte either way. The syscharset oracle needed the flag as well, or it disagrees with the engine on any ACP that best-fits. Found by the httrack-windows session while finishing its newlang.cpp UTF-8 work.