v1.4: diagnose and fix C_livery populated-section boundary drift

[Datamining00]

Diagnostic/fix derivative of v1.4-baseline-warning-render.

Confirmed diagnostic result

• The Warning Only source_offset normalizer did not move any layers in the Fluorite AKE Left/Right sections.
• Therefore the observed Left-side occlusion is not caused by global or per-section source-offset reordering.

Boundary finding

For sample Livery_3761_20260818134954 / C_livery, structurally valid 32-byte placements occur at populated-section boundaries where the pinned decoder unconditionally advances by LIVERY_POPULATED_REMNANT_SIZE (18 bytes). That skip causes the next section's first placement to be missed and shifts ownership of later placements across the boundary while counts can still appear correct.

Observed boundary pattern:

• Top -> Left: valid placement before the decoder's current Left start.
• Left -> Right: valid placement before the decoder's current Right start.
• Left can still report its declared count while containing the wrong terminal placement.

Fix under test

livery_section_boundary_fix_patch.py suppresses the legacy 18-byte populated remnant skip only when all of the following are true:

1. the current populated section has reached its declared placement count;
2. the next section is also populated; and
3. the exact current parser position is already a structurally valid direct 32-byte shape/raster placement.

No layer reversal is used. No source-offset sorting rule is changed. No Car ID or section name is hard-coded.

Validation

• Added targeted regression tests for immediate 00/01 02 placement boundaries.
• Full Windows CI regression suite passes.
• A separate FH6 Assistant v1.4 Section Boundary Fix Test.exe artifact is built for real-save visual validation.

This PR remains draft until the Fluorite AKE Left-side render is validated against the in-game/reference appearance.