[#126.1] Fix jumping effect on initial layout by using lazy initialization

[thomasnemer]

Summary

Fixes the "jumping effect" described in issue #126 where components would appear with incorrect dimensions on initial layout, then "snap" to correct layout on the first window resize.

Root Cause

setAxisResizeBehavior() was initializing originalWidth/originalHeight immediately when called, before FlexLayout had a chance to set proper dimensions. This caused components created with partial sizes (e.g., withSize(300, 0)) to capture originalHeight=0 as their "original" dimension.

When the first window resize occurred, the FIXED/FILL axis behaviors would use these incorrect baseline values, causing the layout to differ from the initial state.

Solution

• Removed early initialization from setAxisResizeBehavior()
• Lazy initialization: originalWidth/originalHeight are now initialized on the first call to onParentResize(), which happens AFTER layout has set proper sizes
• Fallback logic preserved: setBounds() already had fallback logic using current dimensions when original dimensions are 0

Changes

Core Fix

• include/bombfork/prong/core/component.h: Removed initialization block from setAxisResizeBehavior(), added detailed comments explaining the lazy initialization approach

Test Coverage

• tests/test_init_order_bug.cpp: New comprehensive test that verifies:
  • First resize uses correct dimensions (300x600)
  • Subsequent resizes maintain consistency (300x768, 300x480)
  • No jumping effect across multiple resize operations

Test Results

All existing tests pass:

✓ AxisResizeTest
✓ All other tests (18/18 passed)

New test output:

✓ First resize correct!
✓ Second resize correct!
✓ Third resize correct!
✓ Bug is FIXED: No jumping effect, all resizes consistent!

Manual Testing

• Built and tested the demo app
• Verified initial layout matches post-resize layout
• Confirmed no visual "jumping" on window resize

Related Issues

• Resolves [#109.1] Fix jumping effect on initial layout - ensure consistent sizing from startup #126
• Part of the larger window resize handling work

Notes

This is a minimal, surgical fix that addresses the root cause without requiring broader architectural changes. The existing onParentResize() initialization logic already handled this correctly - we just needed to stop initializing too early.