bug: App route does not update on context change when app lacks updated NavigationProvider

[odinr]

Description

When the portal's useAppContextNavigation hook navigates on context change, apps whose internal router relies on history listener events (PUSH/REPLACE) never detect the URL change. The app's route stays stuck on the previous context path — it does not slave to the portal's context navigation.

The root cause: BaseHistory.listen() now filters exclusively for POP actions. The updated NavigationProvider.navigate() compensates by issuing a synthetic pop() after every programmatic navigate, which forces framework routers (React Router, etc.) to re-render. But when the portal navigates on behalf of an app that has an older navigation module — one without this synthetic pop() — the app's router listener never fires, and its route is stale.

// New NavigationProvider.navigate() — has the pop() workaround
this.#history.navigate(this._createToPath(to ?? this.path), { replace, state });
(this.#history as BaseHistory).pop(); // ← forces router to pick up the change

Apps on older @equinor/fusion-framework-module-navigation versions don't have this, so portal-driven context navigation silently leaves them on the wrong route.

Steps to reproduce

1. Run a portal that uses useAppContextNavigation (e.g. portal-analytics cookbook or production portal).
2. Load an app built against an older @equinor/fusion-framework-module-navigation (without the synthetic pop() in NavigationProvider.navigate()).
3. Change context via the context selector.
4. Observe: the browser URL updates correctly, but the app's internal route/view is stuck on the previous context.

Expected behavior

The app's router should detect the portal-driven URL change and re-render the correct route for the new context.

Actual behavior

The app's route remains frozen on the old context path. The URL bar shows the correct new path, but the app content does not update until a full page refresh.

Affected code

• cookbooks/portal-analytics/src/useAppContextNavigation.ts
• packages/dev-portal/src/useAppContextNavigation.ts
• Portal repo — has its own useAppContextNavigation implementation that needs the same fix

Impact

Every portal-hosted app that hasn't upgraded to the latest navigation module will silently break on context switch. Users see a stale view with no indication that anything went wrong, and must manually refresh the browser.

Notes

All implementations of useAppContextNavigation across repos (fusion-framework + portal repo) need to be updated in concert. The fix should ensure the navigation call triggers a route update in the app regardless of which navigation module version the app ships.