feat(nav): hover the peek strip to expose the toolbar, auto-close after leaving

[mairas]

Request

On mouse/desktop, moving the cursor over the top peek area should fully expose the auto-hiding navigation toolbar — no click required. When the toolbar was opened this way, it should auto-close again once the cursor has been away from it for more than N seconds.

Current behavior

The toolbar's visibility lives in ChromeVisibilityService (src/app/core/services/chrome-visibility.service.ts) with two independent bits:

• revealed — full toolbar shown; auto-hides after CHROME_IDLE_HIDE_MS (4000 ms) unless hiding is suppressed.
• peeking — a transient 8 px edge cue (.peek-strip) flashed on input, retracting after CHROME_PEEK_MS (1300 ms).

To reveal today you click/tap the peek strip, and the strip is only pointer-targetable during the transient peek flash (.toolbar-host.peeking:not(.revealed) .peek-strip { pointer-events: auto } in toolbar.component.scss). Hovering the revealed toolbar suppresses auto-hide (onPointerEnter → suppressHide()); leaving it re-arms the 4 s idle-hide (onPointerLeave → allowHide() → scheduleHide(CHROME_IDLE_HIDE_MS)).

What's actually new here

The auto-close-after-leaving is already implemented — leaving the revealed toolbar re-arms the 4 s idle-hide. So the genuinely new work is hover-to-expose: making the top edge a persistent hover hotzone that calls reveal(), rather than requiring a click on the transiently-clickable peek strip.

The N question

Reuse the existing CHROME_IDLE_HIDE_MS (4 s). One timeout is simpler than two, and it's already the "tune on real hardware later" default, so hover-exposed and deliberately-revealed toolbars retract on the same clock.

Introduce a separate, shorter N (~2 s) only if testing shows accidental hover-reveals are annoying — a toolbar you brushed open by accident arguably deserves to retract faster than one you deliberately opened. Decision: ship the shared 4 s first; split the constant only if the accidental-hover case proves real. Final values to be tuned on real hardware, consistent with the existing timing comment in the service.

Design notes

• Hover intent / flicker. An 8 px top-edge hotzone firing on any cursor pass near the top will feel twitchy. Require a short dwell (~150–250 ms) in the peek zone before revealing.
• Touch devices have no hover. This is a mouse/desktop enhancement; the existing tap-the-peek-strip path stays for touch. Gate the hover trigger on a hover-capable pointer.
• Don't double-close. Hover-reveal must go through the same revealed/suppress-hide/idle-hide machinery so leaving cleanly re-arms one timer — no competing close paths.
• Accessibility. Keep the current keyboard/focus reveal on .peek-strip intact; hover is additive.

Acceptance criteria

• On a hover-capable pointer, dwelling the cursor in the top peek zone fully reveals the toolbar without a click.
• After the toolbar is hover-exposed, moving the cursor away and keeping it away for N seconds auto-closes it; returning within N keeps it open.
• Touch tap-to-reveal is unchanged; keyboard focus reveal is unchanged.
• No regression to auto-hide suppression while a dialog/menu is open or focus is inside the toolbar.