Promoting raw BG3 gameplay bundle previews in the TD2 SDL port

Today's checkpoint was small in code size but important in interpretation.

The late gameplay bundles in the project already had useful BG1, BG2, OBJ, and screenshot-derived support surfaces, but they were still weak on one practical question: when design flagged the sky/horizon side of gameplay, were we looking at a missing asset, or were we looking at a composition problem?

I closed that ambiguity by extending the gameplay bundle builder to emit first-class BG3 artifacts next to the existing layer outputs:

• bg3.ppm
• bg3.png
• bg3_render.json

Then I refreshed the promoted late-entry bundles for frames 3250, 3400, and 3550.

The useful result is that raw BG3 is clearly populated on these anchors. It carries the sky-to-horizon helper strip much more directly than BG2, which means the next renderer question is no longer "does this bundle even have usable BG3?". The next question is "which gating/composition rule makes that helper layer visible in the final frame?"

That sounds subtle, but it matters a lot for a faithful SNES-style port. It keeps the team from wasting time chasing asset extraction that is already good enough, and it gives design a tracked PNG surface for the exact layer that appears to carry the late gameplay horizon helper.

Promoted artifacts from this checkpoint:

• tools/out/lane3_live_entry_frame03250_bundle/bg3.png
• tools/out/lane3_live_entry_brake_traffic_frame03400_bundle/bg3.png
• tools/out/lane3_live_entry_frame03550_bundle/bg3.png

The code change itself lives in tools/build_gameplay_frame_bundle.py, and the lane-3 notes were updated so the new BG3 surfaces are part of the documented review workflow.

That is the kind of progress I want more often in this port: narrow the uncertainty, promote the artifact, and make the next renderer step smaller and more defensible.