Adds a menu-driven 'Open in New Window' action to the session right-click and dropdown menus so a user can work with multiple chats side by side, and lowers the window min width from 900 to 420 so several narrow chat windows can be tiled next to each other.

How it works

• A secondary window loads the same renderer at the session's hash route with a ?win=secondary flag (placed BEFORE the '#' so HashRouter does not swallow it as the route). The renderer reads the flag from location.search and skips the install/onboarding overlays and the global session sidebar, rendering a single focused chat. It still connects to the shared local gateway over WS, so there is no backend duplication.
• The main process keys secondary windows by sessionId in a small registry: re-opening a chat focuses the existing window instead of duplicating, and each window self-cleans from the registry on close. The primary window is never tracked there.
• Shared navigation guards (external-link handling, will-navigate confinement, preview/devtools/zoom/context-menu wiring) are factored into one helper so the secondary windows cannot drift from the main window's security posture.
• The macOS dock-activate handler now guards on the main window directly, so a dock click restores the primary window even when only secondary windows are open.

Tests

• electron/session-windows.test.cjs (node --test): URL building (flag before hash, encoding, dev vs packaged) and the registry (focus-or-create, restore on re-open, cleanup on close, rebuild after destroy, input validation).
• src/store/windows.test.ts (vitest jsdom): bridge detection and the open-in-new-window action (no-op without a bridge/session id, invokes the bridge, surfaces ok:false and thrown errors).

What does this PR do?

Related Issue

Fixes #

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

How to Test

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform:

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

For New Skills

• This skill is broadly useful to most users (if bundled) — see Contributing Guide
• SKILL.md follows the standard format (frontmatter, trigger conditions, steps, pitfalls)
• No external dependencies that aren't already available (prefer stdlib, curl, existing Hermes tools)
• I've tested the skill end-to-end: hermes --toolsets skills -q "Use the X skill to do Y"

Screenshots / Logs