fix(plugin-context-navigation): guard path adapter against non-app routes

canHandle now rejects URLs that don't parse as a valid app route, so the
path adapter doesn't claim ownership of portal-chrome/non-app URLs.

Author: Noggling

.changeset/plugin-context-navigation_path-adapter-app-route-guard.md

@@ -0,0 +1,5 @@
+---
+"@equinor/fusion-framework-plugin-context-navigation": patch
+---
+
+Fix `createPathAdapter` matching on non-app routes. `canHandle` now rejects a URL when `currentURL.pathname` does not parse as a valid app route (e.g. portal chrome), preventing the path adapter from incorrectly claiming ownership of URLs where there is no app route to encode context into.

packages/plugins/context-navigation/src/adapters/create-path-adapter.ts

@@ -41,12 +41,17 @@ export function createPathAdapter(): ContextNavigationAdapter {
      * Accepts apps with explicit `'path'` strategy or no declared strategy
      * (the path adapter serves as the system-wide default fallback).
      */
-    canHandle({ appContext, routingStrategy }: AdapterResolutionContext): boolean {
+    canHandle({ appContext, routingStrategy, currentURL }: AdapterResolutionContext): boolean {
       // Custom generators mean the app owns its URL shape — the custom adapter handles it, not us
       if (hasCustomContextGenerators(appContext)) {
         return false;
       }
 
+      // Not an app route (e.g. portal chrome) — nothing for this adapter to encode context into
+      if (!parseAppRoute(currentURL.pathname)) {
+        return false;
+      }
+
       const declared = routingStrategy;
       // App explicitly opted into path-segment routing — take ownership
       if (declared === 'path') {