chore(journeys): re-release @modular-react/journeys@1.9.1 to drop the last exact @modular-frontend/core pin

CHANGELOG.md

@@ -6,6 +6,12 @@ Per-package detail lives in the GitHub release tagged `<npm-name>@<version>`.
 
 ## Unreleased
 
+### Fixed — `@modular-react/journeys` re-release drops the last exact `@modular-frontend/core` pin
+
+`@modular-react/journeys@1.9.0` was published in the window between `@modular-frontend/journeys-engine@1.8.0` and `1.8.1`, so its tarball still depends on `@modular-frontend/journeys-engine@1.8.0` — the version that carried `@modular-frontend/core@0.3.0` as a hard, exact-pinned `dependencies` entry (before the shared-peer-dependency change below promoted it to a `>=0.1.0 <2.0.0` peer in `1.8.1`). The net effect: installing `@modular-react/journeys` still dragged in the old engine and its exact `0.3.0` core pin, so consumers pulling `@modular-frontend/core@0.4.0` (for panels/overlays) still needed a manual `@modular-frontend/core` override to resolve the conflict.
+
+This patch re-releases `@modular-react/journeys` (`1.9.0` → `1.9.1`) with no source or API change. Because the workspace now resolves `@modular-frontend/journeys-engine` at `1.8.1`, the republished tarball pins the fixed engine, and the fixed engine expresses `@modular-frontend/core` as the unified `>=0.1.0 <2.0.0` peer — so the whole `journeys → journeys-engine → core` chain admits the current engine line and the override is no longer needed. The Nuxt (`@modular-vue/nuxt@0.4.1`), Vue-journeys (`@modular-vue/journeys@1.3.1`), and engine (`@modular-frontend/journeys-engine@1.8.1`) packages were already re-released onto the permissive range; `@modular-react/journeys` was the last package still transitively carrying the old exact pin.
+
 ### Added — state-keyed overlay host (pick-one, modal)
 
 Implements the counter-proposal from the cat-factory slice-5 triage (`docs/overlay-host-triage.md`): the **overlay host**, a pick-**one**, app-state-keyed, open-contribution modal surface — the modal dual of the render-all panels. Modules (first-party and consumer alike) contribute _windows_ to a host's slot; application state names the one active window by id; the framework mounts it inside a managed modal shell owning the behaviour hand-rolled modals get wrong somewhere: teleport/portal, backdrop press-and-release close (a press that starts inside the dialog and slips onto the backdrop is not a close request), a shared overlay **stack** (nested overlays layer; Escape closes the top first), focus trap + focus return (re-applied when the active window swaps without closing), body scroll lock, and a11y wiring (`role="dialog"` / `aria-modal` / `aria-label` from the entry's subject-aware `title`). Headless — the host renders only the backdrop and dialog elements (class props + stable `data-modular-overlay-*` e2e hooks); the app's chrome lives in a `wrap` render-prop/slot, and the host never closes itself (it _requests_ close; state stays app-owned). Contributions ride the existing module → slot path; no new registration seam, package, or descriptor change.

packages/journeys/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@modular-react/journeys",
-  "version": "1.9.0",
+  "version": "1.9.1",
   "description": "Typed, serializable workflows that compose multiple modules. A journey declares entry/exit transitions between modules and owns shared state; modules stay journey-unaware.",
   "repository": {
     "type": "git",