[Feature]:Toolbar/page selector should be optionally pinned (or available as a page widget) for pages hosting pointer‑capturing content (Freeboard‑SK, embedded webpage)

[macjl]

Feature Request

Problem

The auto‑hiding toolbar introduced in #183 exposes page navigation through a persistent page‑icon control, but that control only exists inside the toolbar, and the toolbar itself is revealed by mouse‑move / scroll / edge‑peek gestures (#68, #202).

This breaks down on a page that hosts a widget which fully captures pointer/touch input — for example a full‑screen Freeboard‑SK widget or an embedded webpage (widget-iframe). If the embedded content consumes mouse‑move, wheel, or touch events before they reach Skip's shell, the reveal gesture never fires, so the toolbar can't be summoned. This is especially limiting on touch‑only devices (tablets at the helm), where there's no keyboard fallback either — #496 only helps on devices that have a keyboard in the first place.

Expected behavior

At least one of the following should be possible:

1. A setting (global or per‑page) to keep the toolbar — or just the page‑icon navigation control — permanently visible/pinned instead of auto‑hiding. Pinning must reserve real layout space (reflow/resize the page's grid beneath it) rather than staying an overlay, otherwise the pinned bar just permanently covers the top row of widgets.
2. A dedicated, addable "Page selector" widget/component that can be placed directly in a page's grid layout (e.g. a thin strip docked to an edge), sized and positioned like any other widget, independent of the auto‑hide toolbar.

Either option would let a page consisting solely of a Freeboard‑SK or embedded‑webpage widget remain navigable on a touch‑only device, without relying on a gesture the underlying widget might swallow.

Current behavior

Page switching depends entirely on the toolbar reveal gesture (mouse‑move, wheel, edge‑peek, or a hotkey if the shell happens to have keyboard focus). There is no way to pin the toolbar/page control without it overlapping content, and no way to add it as a standalone page component.

Suggested direction

• Pin mode: reuse chrome-visibility.service / page-nav-control (PR-1: Navigation chrome — auto-hiding toolbar, scroll-intent nav, page-icon control, alarm badge #185), but when pinned, switch the toolbar's CSS from position: absolute/overlay to occupying a fixed row in the page's layout, and shrink the grid's available height accordingly (similar to how a normal top app-bar would reflow content).
• Widget mode: expose page-nav-control as a regular widget type droppable into any page's grid — this avoids the reflow question entirely since it's just another grid cell.

Related: #183 (navigation redesign that introduced the auto‑hiding toolbar and page‑icon control), #496 (toolbar auto‑hide also breaks keyboard access — a related but distinct trigger, since it doesn't help touch‑only devices).

Concepts, Ideas & Research

No response