feat(hub): pin the app controls while a library scrolls

Files, Videos, Music and Photos are read by scrolling, and everything that
steers that reading left with the first screenful. Three bands now pin under
the navigation bar, in a group and on the Search page alike: the tab bar (the
search field, on Search), the application's own toolbar, and the file table's
column heads. The group's name and description still scroll — they say nothing
a reader needs while walking a directory, and the height they would cost is
height the list does not get.

A band's offset is the heights of the bands above it, and those are not
constants: the toolbar wraps to three rows on a phone, grows a field while a
folder is being named, and loses its filter on Search. So each band measures
itself and publishes `--chrome-h` / `--toolbar-h` (static/sticky.js) and the
stylesheet does the arithmetic in calc(), rather than a number written down
twice — the fault CLAUDE.md already records against this layout twice over.
A band publishes height *plus its own bottom margin*, and paints that margin
as a ring of page colour, so the pinned layout is pixel-identical to the flow
layout and nothing shifts at the moment a band pins.

Three overflow faults came out of it, all of the same class and all of them
what "the header does not stay" actually meant on Android — a document wider
than the screen leaves everything pinned attached to a viewport the reader can
no longer see, the navigation bar included:

  - a directory's name cell was a bare <td>, so an unbreakable folder name
    (`Rage_Against_The_Machine_Discography_1992-2000_FLAC`) set the column's
    minimum: a 527px table in a 390px window
  - Search's group column did the same at 442px with an underscored group
    name. It also goes entirely below 768px, where there is no room for it and
    the breadcrumb already names the group
  - the shared-directories table has four columns of controls with a combined
    minimum near 440px, none of it compressible. On a phone the row stops
    being a row: the name and its eject/remove pair on one line, the two
    switches — each carrying the column head's own string as a label — on the
    next
  - and, found by measuring at 360px, the tab bar itself was 19px too wide

`.file-table` moves to separated borders: a collapsed border belongs to the
table rather than to the cell, so the column heads lost their rule the moment
they pinned.

Measured, not read. tests/harness/sticky_header_probe.py drives the shipped
GroupPage and SearchPage against a stub node, walks to each application,
scrolls to the end and reports every rectangle — 11 views x 4 widths x 2
engines. Its fixture says what real data says: the first version used
`note-007.txt` and `un groupe`, which fit any screen, and found none of the
above. A fixture narrower than real data tests the fixture.

Also: `test_desktop_shell` no longer looks for the CSP after the first `-->`,
which made it fail on correct markup as soon as a comment was added above it,
and `search-page.js` joins test_hook_ordering's file list.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Tx16FhyD2BUdpooGb5jcyN

1 files changed, 16 insertions, 1 deletions

diff --git a/docs/apps.md b/docs/apps.md
index 85b39da..8054802 100644
--- a/docs/apps.md
+++ b/docs/apps.md
@@ -236,6 +236,19 @@ registry, so a newly-registered app gets a checkbox for free.
    through `saveDirectories`; anything only this app has, it does itself with
    the transport. **Do not import `group-settings.js`** — that is a cycle, and
    it fails as a component that silently does not render.
+2c. **The toolbar pins.** If the app has a toolbar — a row of controls above
+   whatever it is the app shows — give it `position: sticky` on the pattern
+   `style.css`'s "Sticky chrome" section holds, so that scrolling a library
+   does not take its own controls off the screen. Two conditions come with it,
+   and both are structural rather than cosmetic: the toolbar must be a
+   **direct child of the page root** (an app renders a fragment, so it already
+   is — do not wrap it in a container of your own), and it must be **opaque**,
+   or the content scrolls visibly through it. If anything of the app's pins
+   *below* that toolbar, as Files' column heads do, the toolbar has to publish
+   its own height with `useStickyBand` from `sticky.js` — its height is never
+   a constant, since it wraps on a phone. An app with no toolbar renders none:
+   an empty band still holds a strip of the page open, which is why Photos
+   draws no toolbar on the Search page.
 3. **Node-side allow-list**: add the key to `ALLOWED_APPS` in
    `webrtc_server.py`. Without this the node refuses `apps_enabled` for any
    set naming it (`"Unknown app(s): ..."`), so an operator can never turn it
@@ -252,7 +265,9 @@ registry, so a newly-registered app gets a checkbox for free.
    to every `.js` in `static/` (`sw.js` excepted, unversioned on purpose).
    Written after `source-merge.js` shipped missing from the list.
 6. **Test coverage that scans the file set**: `test_hook_ordering.py`
-   (`STATIC_FILES`) and `test_transport_contracts.py`
+   (`STATIC_FILES`), `test_sticky_header.py` (add a case to its probe if the
+   app has a toolbar — a band that stopped pinning looks exactly like one that
+   never did) and `test_transport_contracts.py`
    (`test_no_setter_survives_the_state_it_belonged_to`, `SPLIT_FILES`) walk a
    fixed list of files looking for a whole class of bug each — add the new
    file to both lists, or it is simply never checked, which fails silently