fix: expose upcoming navigation target via routerStateSignal during chain construction

[Artur-]

Updates routerStateSignal in AbstractNavigationStateRenderer.handle() before the new layout/view chain is instantiated, so code running in constructors (e.g. a Signal.map() bound via bindText) sees the upcoming location, route parameters and navigationTarget instead of the previous state. Previously the signal was only refreshed in handleAfterNavigationEvents, after construction, causing reactive mappings on navigationTarget() to NPE during the ElementEffect probe.

Fixes #24471

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
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

[github-actions]

Test Results

 1 427 files  ±0   1 427 suites  ±0   1h 23m 4s ⏱️ -48s
10 036 tests +1   9 968 ✅ +1  68 💤 ±0  0 ❌ ±0 
10 508 runs  +1  10 439 ✅ +1  69 💤 ±0  0 ❌ ±0 

Results for commit 9967940. ± Comparison against base commit 33e3565.

[Artur-]

Is this wrong aka it updates the info too early? Should it only be done for the first navigation to avoid that navigationTarget can ever be null? Should it not be done at all?

[mcollovati]

I'm not 100% sure about this being a fix for an issue or a new feature.
RouterState Javadoc explicitly mentions the case for navigationTarget

null before the first navigation completes.

On the other hand, RouterState is defined as an immutable snapshot of a UI's current navigation state; so also the before navigation could be considered a valid state to notify.
But only giving an empty active chain as a hint of before navigation does not sound so good.

I would either not apply any change, since the case is documented, or do an early update for the first navigation only, but making it explicit by using a RouterState subclass (e.g. PendingRouterState). This is a new feature in 25.2, so I guess we can still change it a bit.

[Artur-]

I don't think the signal should work differently though - it should be in sync with the router state so no matter how you access the router state in a constructor, it should be the same