Edit Content shell shows referring portlet's breadcrumb / active menu when opened from another portlet

Description

When a user opens the Edit Content shell (/dotAdmin/#/content/{inode}) from a tab or window that isn't content-drive, the chrome of the page shows the referring portlet's breadcrumb and menu highlight instead of the breadcrumb that belongs to Edit Content itself.

Concrete scenario:

1. User is in any portlet other than content-drive (e.g., Query Tool, ES Search, Tags) at /dotAdmin/#/<portlet>.
2. User opens a contentlet whose Content Type has CONTENT_EDITOR2_ENABLED=true in a new browser tab (or any flow that lands directly at /dotAdmin/#/content/{inode}).
3. The new tab loads /dotAdmin/#/content/{inode} — URL is correct, the Edit Content form renders correctly.
4. But the breadcrumb shows Home > Dev Tools > Query Tool (the referring portlet, or whatever the last menu activation was) instead of Home > Content, and the left menu still highlights the referring portlet.

Expected (verified by directly typing /dotAdmin/#/content/{inode} in a clean session or via the canonical content-drive flow): breadcrumb should resolve from the active URL path → Home > Content, and the left menu should highlight the Content group / Search item.

The Edit Content form itself is correct and functional — the issue is purely the surrounding chrome (breadcrumb + active menu).

Acceptance Criteria

• Opening /dotAdmin/#/content/{inode} in a fresh browser tab renders the breadcrumb Home > Content > <title> regardless of which portlet the link came from
• The left menu highlights the Content group / Search item when on /dotAdmin/#/content/{inode}, not the previously-active portlet
• The fix works for all entry paths: direct URL, window.open(_blank), in-tab navigation, and middle/cmd-click on any anchor that points to /content/{inode}
• The legacy edit-content path (/c/content/{inode}) chrome is reviewed alongside; if it has the same problem, decide whether to fix or document it as a known legacy limitation
• No regression for the existing content-drive → Edit Content flow (breadcrumb + menu state stay correct)

Priority

Medium

Additional Context

Surfaced while validating the Query Tool migration (#35709). The Query Tool now opens result-row clicks via window.open(_blank) with /dotAdmin/#/content/{inode}, which exposes this chrome behavior; the same issue is reproducible from ES Search and any other portlet that links into Edit Content.

The bug lives in whichever component computes the breadcrumb / menu-active state for the Edit Content route — it appears to read from a stateful "last activated portlet" instead of resolving from the current URL path. Two candidate fixes for the implementing team to choose between:

1. Resolve from URL on activation. Inside the Edit Content shell (or its parent route guard/resolver), detect the active path and force-set the breadcrumb + menu state to "Content" before the form renders.
2. Make the breadcrumb a pure derivative of the route tree. Drive it from ActivatedRoute data rather than from a stateful service that only updates on menu clicks.

Repro steps:

1. Open /dotAdmin/#/query-tool (or any portlet other than content-drive).
2. Run a query that returns content of a type with the new editor enabled (e.g., +contentType:BulkProduct +live:true +languageId:1 on the demo site).
3. Click a result title (opens in a new tab with the Query Tool implementation, or Cmd+Click from any other portlet that links to /content/{inode}).
4. Observe the breadcrumb in the new tab: shows the referring portlet's crumb chain.