Fix wide tables overflowing their viewport by the leading gutter

[jedrzejsieracki]

Fix wide tables overflowing their viewport by the leading gutter

Problem

In "wide surface" mode, a table's card overflows its scroll viewport by exactly
the leading gutter width. On platforms with classic (non-overlay) scrollbars —
Windows — this is plainly visible: a horizontal scrollbar strip as wide as the
whole window appears below the table, and the table's last column is clipped
past the visible right edge until the user scrolls. On macOS the same overflow
exists but is masked by overlay scrollbars and by typically smaller gutters, so
it presents there only as a hidden scrollable region.

Root cause

layoutTable positions a wide table by giving the wrapper an inline
margin-left: -gutter and exposing --table-leading-gutter, and the CSS shifts
the sizer back into text alignment:

.table-scroll.is-wide .table-sizer {
  margin-left: var(--table-leading-gutter, 0px);
}

The margin moves the sizer right without shrinking it — the sizer keeps
width: 100% of the viewport, so it extends gutter pixels beyond the
viewport's right edge and the viewport becomes scrollable by that amount.

Measured after resizing the window to 1650 px with the reading width fixed
(showcase, "Project pulse" table, before this fix):

viewport: clientWidth 1498, scrollWidth 2099   ← overflow = 601 px
sizer rect: 677…2175                           ← 601 px past the visible edge (1574)
gutter (--table-leading-gutter): 601 px

Fix

Subtract the gutter from the sizer's width so the card ends at the surface
edge:

.table-scroll.is-wide .table-sizer {
  margin-left: var(--table-leading-gutter, 0px);
  width: calc(100% - var(--table-leading-gutter, 0px));
}

The sizer keeps its min-width (the readable per-column width), so when the
remaining surface genuinely cannot fit the table — e.g. an expanded table at a
narrow reading width — the table still overflows and scrolls, which is the
intended behavior.

After the fix, scrollWidth == clientWidth in wide mode at every measured
window width (980 px and 1650 px), and the card starts at the text column's
left edge and ends exactly at the surface's right edge.

Testing on macOS

The overflow is invisible with overlay scrollbars, so verify by measurement:

1. Open the showcase, widen the window well past the reading width so
   "Project pulse" enters wide mode.
2. In the web inspector, for the table's .table-viewport check that
   scrollWidth === clientWidth (previously it exceeded it by the gutter).
3. Visually: the table card must remain aligned with the text column on the
   left and end at the shell's right padding; expanding/collapsing and window
   resizes must keep that geometry.

On Windows (or with "Show scroll bars: Always" on macOS) the stray full-width
scrollbar strip below wide tables disappears.

Tests

• testWideTableKeepsReadableColumnsAndExpandsIndependently
  (EditorWebViewTests) was reviewed line by line: its web view is 900 px wide
  (surface ≈ 820 px), narrower than the table's 864 px minimum, so the
  sizer's min-width dominates there and every asserted geometry metric is
  unchanged by this rule. The rule only removes the phantom overflow that
  appeared when the surface was wider than the table — a regime the test does
  not exercise.
• RendererStylesTests asserts on .table-viewport, table, and th, td
  rules; this change touches only .table-scroll.is-wide .table-sizer.
• swift test runs on macOS CI (this patch was authored on Linux, where the
  Swift suite cannot run).
• Screenshots from a Windows host (before: full-window-width scrollbar strip +
  clipped last column; after: clean card) are attached to this PR.

Scope

One CSS rule in Resources/Renderer/renderer.css. No JS, API, or payload
changes. Found while building the experimental .NET port slice
(docs/PORTING.md); independent of the accompanying table-relayout fix and
merges in either order.