v1.4: compare patched 3.1.27 vs clean KFPS 3.1.31 decoders

[Datamining00]

Goal

Generate a per-livery differential JSON between:

• KFPS 3.1.27 + the last proven FH6 Assistant decoder rules; and
• clean KFPS 3.1.31.

Behavior

Opening a livery preview keeps the visible renderer on clean KFPS 3.1.31, but also decodes the same C_livery through an isolated 3.1.27 module with the legacy FH6 Assistant decoder rules. The report is saved under %LOCALAPPDATA%\FH6GarageAnalyzer\decoder_differential.

The JSON records per-section counts, first order divergence, source-offset-only layers, semantic differences (section/type/shape/mask/raster/transform/color), and both decoder reports. It does not automatically choose between decoders and does not modify the save.

Bundling

The build vendors both exact KFPS commits:

• legacy: 8965780b8966e09d2f2a17e4d0684cdd44d7437c
• current: 004b3b61a57d901e65957b6099805835f91e32f6

Validation

• Windows CI run: 32391071709 — success
• Regression suite: 193 tests, OK
• PyInstaller one-file build: success
• EXE bytes: 82,686,323
• EXE SHA-256: 922c27b0dc71a2a3d3b425156f3dfcc7bc7d701144652412e60779dd33a3170e
• Artifact ZIP SHA-256: 93e69a7f2b75b9a2d6c16e4d14233a485c11502fab7ce0d346c18f9669439ccb

Real-data procedure

Run the build on at least two contrasting liveries:

1. one that was correct on the patched 3.1.27 build but regressed on clean 3.1.31;
2. one that failed on the patched 3.1.27 build but works on clean 3.1.31.

Open each livery preview once, then collect the generated decoder-diff-*.json files. Those reports should identify the earliest grammar/ownership/order divergence before any hybrid compatibility rule is designed.

Draft diagnostic only. Do not merge before real-livery comparison.