fix: restore Windows Unicode CLI path arguments for jar and native

[kireetivar]

On Windows, non-ANSI characters in host path options (for example--from-cache, -f / --file, --source-dir) can be corrupted before main sees them. Any code points outside the active ANSI code page (sun.jnu.encoding, often Cp1252) can become ? (JVM) or U+FFFD (some Graal native builds).

This change restores those arguments at process entry for both:

• java -jar fcli.jar
• Graal native fcli.exe

by re-reading the process command line with the wide Win32 APIs GetCommandLineW + CommandLineToArgvW (same pattern used by native CLIs and libraries such as boost.nowide / Python on Windows), then replacing only tokens that look like a lossy form of the wide originals.

References (upstream / platform)

OpenJDK / java.exe launcher

• JDK-8368853 — Windows java CLI cannot handle Unicode characters in arguments
  java.exe obtains UTF-16 via GetCommandLineW but re-encodes through the
  ANSI code page, turning unmappable characters into ? (or ?? for
  supplementary characters). Status: Won't Fix.
• JDK-8124977 — cmdline encoding challenges on Windows
  Related discussion of Windows command-line encoding and the need for wide APIs.

Related property: sun.jnu.encoding (encoding used when parsing values from the command line on the JDK).

GraalVM native-image

• oracle/graal#8593 (GR-52826) — Non-ASCII characters in command line arguments are replaced by U+FFFD in Windows (native-image)
  Native images on Windows have been observed to replace non-ASCII argv
  characters with U+FFFD. Open issue; not fixed in the platform.

Because neither the JDK launcher nor (historically) Graal native-image guarantees intact Unicode argv on Windows, fcli recovers args in-process when needed.

Approach

Area	Change
Entry	FortifyCLI.main calls WindowsCommandLineArgs.fixIfNeeded(args)
Recovery	JNA → GetCommandLineW / CommandLineToArgvW; merge only corrupted tokens
Scope	Windows only; no-op if sun.jnu.encoding is UTF-8; never throws
Coverage	JVM (? via jnu round-trip) and native-style (U+FFFD) corruption
Deps	net.java.dev.jna:jna (core only)
Native	JNA reachability metadata + --initialize-at-run-time=com.sun.jna

NOTE: Alternatively, we can skip this recovery approach entirely and simply throw an exception when non-ANSI / corrupted characters are detected in the host-path arguments, if that is considered a cleaner / better solution.