Fix recursion panic in geometry property callbacks (#7402, #7849)

[tilladam]

Summary
This PR fixes a recursion panic that occurred when using changed callbacks on geometry properties (like width or height) within layouts containing conditional elements (if or for loops).

Previously, ChangeTracker::init() would immediately evaluate properties, triggering layout computations. In scenarios involving dynamic components (repeaters/conditionals), this led to recursive ensure_updated() calls and subsequent panics during component initialization.

Changes

Core:
Introduced init_delayed() for ChangeTracker to defer the first property evaluation until run_change_handlers() is called.
Added a new initialization_scope module with defer_initialization() and InitializationScope RAII guards.
Refactored ChangeTracker FFI to support delayed initialization and added safety guards (evaluating flag) to prevent use-after-free.
Generators & Interpreter:
Updated Rust and C++ generators to wrap component creation in an initialization scope.
Updated the interpreter to use init_delayed.
Tests:
Added reproduction test cases for issues Querying geometry property from init callback can cause 'Recursion detected' #7402 and #7849.
Updated changes.slint expectations to reflect the new callback ordering.
Fixes

Fixes Querying geometry property from init callback can cause 'Recursion detected' #7402
Fixes #7849

[ogoffart]

I finally had time to look at this PR.

The problem it solves is real, but i'm not sure this is the right way to do it.

I'm thinking the real problem here, which causes many problem, is that elements get instantiated when as we visit the item tree to instantiate property.

Consider this example:

export component Example inherits Window {
    layout := HorizontalLayout {
        if true: Rectangle {
            init => {
                debug(layout.preferred-width);
            }
        }
    }
}

This will basically create a fake binding on the layout's preferred-with that will visit all its children and add their preferred-width. The problem is that reading the preferred-width property, which is lazy, will evaluate it, and this will cause instantiation of item. And this will query the value of preferred-width from the init callback.

I see a few way out of it:

1. We should properly detect this kind of binding loop at compile time, which means that the binding_analysis should consider the changed properties and the init callback in visit_layout_items_dependencies (we currently already visit the model via recurse_expression(&element, &r.model, vis) but we also should visit all the init and changed callback of the generated component.

2. The real problem is that the init callback can have side effect when reading a property.
   prehaps we should not call ensure_updated when visiting the layout's geometry. Instead, we could instentiate the repeater in a call similar to ChangeTracker::run_chage_handler.
   That might be a breaking change, especially for some of our tests. But i think this has caused problem before that the init callback can cause property to change as we try to redraw a scene or something.

[tilladam]

Thanks for the detailed feedback! I've implemented Option 1 (compile-time detection) as a complement to the runtime fix.

What's implemented:

The binding analysis now visits properties tracked by changed callbacks in repeated components when processing layouts. This detects the binding loop at compile time:

warning: The binding for the property 'height' is part of a binding loop (... -> gb.height -> layoutinfo-v -> ...).
         This could cause unexpected behavior at runtime

Why warnings instead of errors:

I made these warnings rather than errors because:

1. Users can't always avoid this pattern - A component author might add changed height without knowing their component will be used in a layout repeater. The composition is valid in isolation.

2. The runtime handles it gracefully - With init_delayed() and InitializationScope, the code runs correctly. The callbacks just fire after initialization completes, which is arguably better behavior anyway.

3. False positives are possible - The static analysis is conservative and may flag cases that wouldn't actually cause issues at runtime.

Why not Option 2 (don't call ensure_updated during layout):

This would be a significant architectural change with unclear benefits. Layout needs to know about all children to compute correctly - if repeaters aren't instantiated, we'd get incorrect layout results. The current approach (defer callback execution, not component instantiation) achieves the same goal with less disruption.

Summary:

• Runtime fix remains the primary solution (prevents panic, handles edge cases)
• Compile-time warning alerts users to the pattern so they can investigate if needed
• Code compiles and runs correctly in all cases

[ogoffart]

Thanks.
Would it be possible to extract the change to fix compile-time loop detection in another PR? (Separated from the InitializationScope changes)

[tilladam]

Done with #10552

[bryce-happel-walton]

@ogoffart Can this be merged?

[ogoffart]

Had a short talk with @tronical about this. We will close this PR for now.
This PR adds lots of complication and we're not ready to maintain this kind of code.
Especially since some property would be initialized delayed and some not in a non-intuitive way.
Acceptable solution would be to improve the compiler to detect these loop at compile time (#10552)

It may be also possible to consider always initializing the changed callback with a delay.
This would be a change in behavior though, but it may be acceptable.