test(web): assert the timestamp occlusion the sidebar gutter fixes

The e2e measured the reserved band but never the symptom the change is
named for. Headless chromium defaults to an overlay scrollbar, which is
the configuration where a bar can cover row content at all, so the
scenario already ran in the right mode: against clean master the band is
0 and the bar covers 7px of the relative time.

Adds timeCoveredBy, the overlap between the relative time's right edge
and the range the bar occupies, taking the bar's width from the sheet
where it applies and from the UA's overlay width otherwise. Assuming 0
there would report no occlusion in precisely the state that has it.

Keeps the band assertion rather than replacing it: the two catch
different regressions. Removing only scrollbar-gutter leaves
timeCoveredBy at 0, because the bar is then 8px and the row's right
padding is also 8px, so it abuts the timestamp without covering it.
Removing the pseudo-element width as well is what produces the overlap.
Each was mutation-checked with the other assertions in its test silenced.

Records in the note that the gutter and the ::-webkit-scrollbar width are
jointly necessary against an overlay bar, measured by deleting each from
the live cascade with the other in force: either alone drops the band
from 8 to 0.

apps/web/tests/sidebar-scrollbar.e2e.ts

@@ -14,11 +14,35 @@
 //
 // Headless-chromium caveats, load-bearing for what is asserted below.
 //
-// Chromium paints an OVERLAY scrollbar that consumes no layout width, so
-// comparing the time element's right edge against the list's client-area right
-// edge holds with and without the reservation and proves nothing; the reserved
-// band width is the only layout signal that distinguishes the two states. See
-// the assertions for which one is the control.
+// Headless chromium defaults to an OVERLAY scrollbar: one drawn on top of the
+// content, consuming no layout width unless something reserves space. That is
+// the mode in which the reported symptom exists at all, so this environment
+// reproduces it rather than merely approximating it — measured against clean
+// master, where the list's band is 0 and the bar covers 7px of the relative
+// time. (Under a classic space-consuming bar, `clientWidth` already excludes
+// the bar and nothing can be covered; a headed run under xvfb behaves that way
+// and cannot show the symptom.)
+//
+// The consequence for assertions: comparing the time element's right edge
+// against the list's CLIENT-area right edge holds in both states and proves
+// nothing, because with an overlay bar the client edge is the border edge. The
+// two signals that do separate the states are the reserved band width and
+// `timeCoveredBy`, which measures the overlap against the bar's own width.
+//
+// Both the `scrollbar-gutter: stable` reservation and the sheet's
+// `::-webkit-scrollbar` width are needed for that band, and neither suffices:
+// measured on the running app, deleting either one takes the band from 8 to 0
+// while the other stays in force. The gutter states that space be reserved; the
+// pseudo-element width is what makes chromium treat the bar as occupying layout
+// space in the first place.
+//
+// That conjunction is why `band` and `timeCoveredBy` are both asserted and
+// neither replaces the other. Removing only the gutter leaves `timeCoveredBy` at
+// 0, because the bar is then 8px wide and the row's right padding is also 8px,
+// so it abuts the timestamp without covering it; `band` catches that case.
+// Removing both — the actual master state — is what produces the reported
+// overlap, and `timeCoveredBy` measures it at 7. Each was mutation-checked with
+// the other assertions in its test silenced.
 //
 // Chromium also takes the `::-webkit-scrollbar*` path, not the standard
 // properties: scrollbar.css gates `scrollbar-width`/`scrollbar-color` behind
@@ -74,6 +98,14 @@ interface ListMetrics {
   borderRight: number
   /** Right edge of the first row's relative-time element, the content the unreserved bar covered. */
   timeRight: number
+  /**
+   * Pixels of the relative time the scrollbar paints over: how far its right
+   * edge reaches into the band the bar occupies, `[borderRight - barWidth,
+   * borderRight]`. This is the reported symptom as a number, and it is the one
+   * geometric signal that separates the two states in this environment — see
+   * the file header on why `clientWidth` comparisons cannot.
+   */
+  timeCoveredBy: number
 }
 
 /**
@@ -119,9 +151,11 @@ function measureList(page: Page): Promise<ListMetrics> {
       .filter(rule => rule.selectorText === '::-webkit-scrollbar-thumb:hover')
       .map(rule => rule.style.getPropertyValue('background'))
     const style = getComputedStyle(list)
+    const pseudoWidth = getComputedStyle(list, '::-webkit-scrollbar').width
+    const barWidth = pseudoWidth === 'auto' ? 15 : Number.parseFloat(pseudoWidth)
     return {
       gutter: style.scrollbarGutter,
-      width: getComputedStyle(list, '::-webkit-scrollbar').width,
+      width: pseudoWidth,
       track: getComputedStyle(list, '::-webkit-scrollbar-track').backgroundColor,
       standardWidth: style.scrollbarWidth,
       standardColor: style.scrollbarColor,
@@ -133,6 +167,14 @@ function measureList(page: Page): Promise<ListMetrics> {
       clientRight: list.getBoundingClientRect().left + list.clientWidth,
       borderRight: list.getBoundingClientRect().right,
       timeRight: time.getBoundingClientRect().right,
+      // The bar is drawn in the rightmost `barWidth` of the border box, whether
+      // or not that space was reserved. Its width comes from the sheet where the
+      // sheet applies, and from the UA's own overlay bar otherwise — 15px is
+      // what this chromium paints, measured against master where the rule is
+      // absent. Taking the UA width as the fallback is what keeps the assertion
+      // honest: assuming 0 there would report no occlusion precisely in the
+      // state that has it.
+      timeCoveredBy: Math.max(0, time.getBoundingClientRect().right - (list.getBoundingClientRect().right - barWidth)),
     }
   })
 }
@@ -201,11 +243,19 @@ describe('web e2e: sidebar session list scrollbar (reserved gutter / themed thum
     // drawn over it. Removing the declaration makes it exactly 0. The value
     // itself is not pinned — it tracks `scrollbar-width` and the platform.
     expect(metrics.band).toBeGreaterThan(0)
-    // With the band reserved, the row's relative time — flush against the
-    // row's right padding, the element the unreserved bar covered — ends
-    // inside the content area, clear of the bar. Alone this would be vacuous
-    // under chromium's overlay scrollbar (see the file header); it is
-    // meaningful only conjoined with the band assertion above.
+    // The reported symptom, stated directly: no part of the row's relative time
+    // lies under the bar. Measures 7 on clean master — the `h` of `1h` is the
+    // covered part. Unlike the client-edge comparison below it does not go
+    // vacuous under an overlay scrollbar, because it measures against the bar's
+    // own width rather than against a content edge the overlay bar does not
+    // move. It is not a replacement for the band assertion above; see the file
+    // header for which regression each one catches.
+    expect(metrics.timeCoveredBy).toBe(0)
+    // Corollaries of the reservation, kept because they pin where the band sits
+    // rather than only that it exists: the time ends inside the content area,
+    // and the content area ends before the border box. Each holds in both
+    // states on its own (see the file header) and is meaningful only alongside
+    // the two assertions above.
     expect(metrics.timeRight).toBeLessThanOrEqual(metrics.clientRight)
     expect(metrics.clientRight).toBeLessThan(metrics.borderRight)
     expect(tripwire.pageErrors).toEqual([])