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

[kibertoad]

What & why

Closes the residual from the @modular-frontend/core shared-peer-dependency work (#95): a consumer still needs a manual @modular-frontend/core override, and the last remaining cause is @modular-react/journeys.

@modular-react/journeys@1.9.0 was published in the window between @modular-frontend/journeys-engine@1.8.0 and 1.8.1. Its published tarball therefore still depends on @modular-frontend/journeys-engine@1.8.0 — the engine version that carried @modular-frontend/core@0.3.0 as a hard, exact-pinned dependencies entry. (1.8.1 promoted that to a >=0.1.0 <2.0.0 peer.) So installing @modular-react/journeys still drags in the old engine and its exact 0.3.0 core pin, and any consumer pulling @modular-frontend/core@0.4.0 (for panels/overlays) still hits the peer conflict the override was papering over.

The sibling packages named in the original report are already clean on npm:

package	latest	@modular-frontend/core reach	status
@modular-vue/nuxt	0.4.1	peer >=0.1.0 <2.0.0	✅ already released
@modular-frontend/journeys-engine	1.8.1	peer >=0.1.0 <2.0.0	✅ already released
@modular-vue/journeys	1.3.1	→ engine 1.8.1	✅ already released
@modular-react/journeys	1.9.0	→ engine 1.8.0 → dep core@0.3.0	❌ this PR

This PR bumps @modular-react/journeys 1.9.0 → 1.9.1 with no source or API change. The dependency on the engine is workspace:*, and the workspace now resolves @modular-frontend/journeys-engine at 1.8.1, so the republished tarball pins the fixed engine. That makes the whole journeys → journeys-engine → core chain express the unified >=0.1.0 <2.0.0 range, and the @modular-frontend/core override is no longer needed anywhere in the tree.

Release path: release-same-version (the version committed here, 1.9.1, is the intended publish target — see .github/workflows/publish.yml).

How it was verified

• Confirmed against the live npm registry that @modular-react/journeys@1.9.0 still resolves @modular-frontend/journeys-engine@1.8.0, and that 1.8.0 declares dependencies: { "@modular-frontend/core": "0.3.0" } while 1.8.1 declares it as a >=0.1.0 <2.0.0 peer.
• Confirmed nuxt@0.4.1, journeys-engine@1.8.1, and vue-journeys@1.3.1 already ship the permissive range, so no republish is needed for them.
• Verified packages/journeys depends on @modular-frontend/journeys-engine: workspace:* and the workspace engine version is 1.8.1, so pnpm publish rewrites the pin to 1.8.1 in the tarball.
• pnpm install --lockfile-only produced no lockfile change (an importer's own version isn't tracked there); oxfmt --write . clean.

Checklist

• pnpm lint — oxfmt --write . run over the repo (version/CHANGELOG-only change; no code touched).
• Tests cover the change and pass — N/A: no source change; the fix is entirely in the published dependency graph, verified against the npm registry as above.
• Docs / CHANGELOG updated — CHANGELOG.md "Unreleased" gains a "Fixed" entry.
• Vue impact stated. No Vue follow-up needed: @modular-vue/journeys@1.3.1 already depends on the fixed @modular-frontend/journeys-engine@1.8.1. This PR only re-releases the React binding that lagged behind the engine fix.

---

Generated by Claude Code

[coderabbitai]

Warning

Review limit reached

@kibertoad, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 19 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 7408e2c9-3120-474d-8953-052555751571

📥 Commits

Reviewing files that changed from the base of the PR and between 9491014 and e9d1891.

📒 Files selected for processing (2)

• CHANGELOG.md
• packages/journeys/package.json

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/dependency-version-ranges-m7mrha

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}