fix(ourlogs): stabilized column widths during scrolling

[JoshuaKGoldberg]

This is another one that ballooned a bit from where I thought it was. We don't actually store grid column widths by default / on page load, they're just CSS minmax with auto. The user dragging a column to manually resize just sets that column in columnWidthsRef.current.

As a result, LOGS-796 happens when:

1. There is a column that has not been manually resized
2. The column sometimes has data, sometimes doesn't
3. The user scrolls so that the table switches between having data in the column's cells vs. not having data

When there's content in the column cells, the table's grid gives that column more auto width. When there isn't content, less auto width.

The fix in this PR is to "lock" the columns when scrolling starts. This is done by measuring the current DOM width and setting it in the DOM styles. The columns get "unlocked" when the page changes from a browser size or field reorder.

We can't unlock when scroll ends, because then we'd get a sudden shift from columns reverting to auto widths from the manually set ones.

Fixes LOGS-796.

[linear-code]

LOGS-796

[github-actions]

📊 Type Coverage Diff

Metric	Before	After	Delta
Coverage	93.49%	93.49%	±0%
Typed	135,187	135,207	🟢 +20
Untyped	9,411	9,412	🔴 +1

🔍 1 new type safety issue introduced

Non-null assertions (!) (1 new)

File	Line	Detail
static/app/views/explore/logs/tables/useLogsTableColumnWidths.tsx	58	domWidths[i + 1]!

This is informational only and does not block the PR.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 7902a63. Configure here.}