fix(converter): align MH3G guide and appearance records

[VincentAdamNemessisX]

Summary

• add a current-only official-transfer parity layer without changing the byte-reproducible 0.0.3-0.0.6 algorithms
• endian-convert all 48 monster-guide records and the omitted player appearance / pigment fields
• teach repair-converted to repair those fields only when the current Wii U value still equals the historical converter output
• preserve signed talisman point bytes and document the legacy-editor unsigned display / armor RGB rewrite caveat
• replace unsafe whole-file system conversion at the CLI boundary with a two-input shared-data merge
• require both the 3DS source system and an existing initialized Cemu system, union only gallery/movie flags, and preserve every other Cemu byte
• add prominent bilingual macOS/Windows warnings that system is shared by all three slots

Official-transfer evidence and exact boundary

The supplied archive was unpacked only under /tmp; no real save is committed. Five independently paired Japanese 3DS -> Wii U official-transfer slots were compared against a fresh conversion from this branch.

For all five pairs:

• payload 0x65C4..0x6684 (48 guide records) matches the official Wii U result byte-for-byte
• appearance fields 0x73B8, 0x73BC, 0x73C8, 0x73D0, and 0x73D8 match byte-for-byte
• the complete 1000-record equipment box matches byte-for-byte
• compatibility repair classified the pre-fix conversion as 0.0.6, repaired 48-53 non-palindromic fields depending on the save, and produced the same bytes as a fresh fixed conversion

This is targeted-field exactness, not whole-file identity. The five converted user# payloads still differ from the supplied official results by 288, 255, 258, 270, and 215 bytes respectively in fields outside this PR's proven mapping. All four quest files matched the official samples before this change and remain untouched.

Shared system decision

Gallery/movie flags live in the shared system component, not the selected user#. Because that file can also carry settings and data shared by the other slots, the converter now:

1. rejects a missing Cemu baseline;
2. validates source as Japanese 3DS system and target as Japanese Cemu system;
3. reads the four known 32-bit source flag words from 3DS file offsets 0x44..0x53;
4. unions them into Cemu file offsets 0x68..0x77 with the correct endianness;
5. starts from the current Cemu bytes and preserves every byte outside that 16-byte range;
6. binds write authorization to both source and target SHA-256 values, with backup, atomic replacement, manifest, and rollback.

The one supplied source/target system sample does not behave as a trustworthy whole-payload official parity oracle, so this is deliberately reported as format/transaction evidence rather than gameplay proof.

Root cause

• The historical MEOW-derived table omitted one contiguous 48 x u32 guide table and a mixed-layout appearance cluster.
• The talisman records themselves already matched official-transfer output. The referenced legacy Wii U editor reads skill-point bytes as uint8_t, so negative points render as 248-255, and its armor writer rebuilds the header without preserving RGB bytes.
• Gallery/movie history is stored in the separate shared system; copying a whole source file would risk unrelated slot/settings data, while converting only user# cannot migrate it at all.

Verification

• cargo test -p mh3g-save-convert — 215 passed
• native and x86_64-pc-windows-msvc Clippy with -D warnings — passed
• swift test — 64 passed
• documentation and Windows source contract checks — passed
• macOS production app build + synthetic smoke — passed
• direct convert-system dry-run on the supplied 3DS/Cemu sample — passed without modifying either file
• git diff --check — passed

Runtime boundary

Cemu was not launched. This is targeted official-transfer byte parity plus system format/transaction and synthetic UI verification, not gameplay runtime verification. Native Windows WinUI compilation/runtime remains for a Windows host.