feat: Add Component.sizeSignal() for tracking component size via ResizeObserver

[Artur-]

Adds a lazily-initialized, read-only signal on Component that tracks the element's size using the browser's ResizeObserver API. A per-UI ComponentSizeObserver manages a single shared ResizeObserver instance and dispatches size updates to individual component signals.

[github-actions]

Test Results

 1 362 files  + 1   1 362 suites  +1   1h 20m 35s ⏱️ - 1m 35s
 9 673 tests + 4   9 606 ✅ + 4  67 💤 ±0  0 ❌ ±0 
10 137 runs  +11  10 061 ✅ +11  76 💤 ±0  0 ❌ ±0 

Results for commit 709c9d4. ± Comparison against base commit d16f71e.

♻️ This comment has been updated with latest results.

[Legioth]

I'd keep this one on hold until we have refined the big picture related to responsive layouting APIs. Some open questions to consider:

• Most responsive layouting is based on specific breakpoints rather than exact pixel values. Would it be useful to express those breakpoints in the API for better ergonomics or to allow client-side filtering of events?
• How important is it to be able to apply certain effect (e.g. adding or removing a CSS class name when some size crosses a breakpoint) immediately in the client without relying on a server round trip?

[Artur-]

I would see this as the building block for higher level features

[Legioth]

I see it as highly visible API that has the risk of not being a practical building block (e.g. if client-side breakpoints are needed)

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud