fix(router): avoid notifying listeners during build on page removal

[Eimen2018]

Summary

Fixes #1184: browser back navigation on a Stacked web app (default stacked create app -t web template) throws setState() or markNeedsBuild() called during build from _RootRouter.

Root cause

Matched against the reported stack trace:

1. Navigator.onDidRemovePage in route_navigator.dart calls router.removeRoute(routeData).
2. StackRouter._removeRoute in routing_controller.dart called notifyAll(forceUrlRebuild: true) unconditionally, even when the page was already gone from _pages (index -1).
3. notifyAll triggers _RootRouterState._handleRebuild, which calls setState().

When the removal is a side effect of the Navigator updating while the router widget's own rebuild is still cascading down into a descendant, that synchronous setState() lands during build and throws.

Fix

lib/src/router/controller/routing_controller.dart, _removeRoute:

• Idempotent removal. If the page is no longer in _pages, return early. Nothing changed, so nothing is notified. This is a deliberate behaviour change: a redundant removeRoute used to still trigger a full rebuild and URL update, now it is a no-op.
• Build-phase guard. When a page is actually removed while SchedulerBinding.instance.schedulerPhase == SchedulerPhase.persistentCallbacks, the notification is deferred with addPostFrameCallback. In every other phase it stays synchronous, exactly as before, so normal navigation timing is unchanged.

The guard sits at the notification point rather than in the onDidRemovePage callback so it also covers the second removal path introduced by #1193 (StackedPage.popped eagerly removing the page). Whichever path removes the page first, the other becomes a safe no-op.

Tests

test/router/browser_back_navigation_test.dart (new):

• Reproduces the exact reported exception on master by removing the top page from a ListenableBuilder inside that page while _RootRouter is rebuilding, then asserts no exception with the fix.
• End-to-end pop via handlePopRoute() asserting no exception across several frames.

Note: on Flutter 3.41 a plain browser or system back alone did not reproduce the crash (the reporter was on 3.35.4), so the first test forces the race directly and is the reliable regression guard.

Verification

• flutter test: 95 passed, 1 pre-existing skip
• dart analyze lib test: no new issues
• No public API change

🤖 Generated with Claude Code

[Eimen2018]

Superseded by #1198, which is the same change opened from a branch in this repository instead of a fork so that CI can post the coverage report.