[HalfSweet]

Deep into a long capture the ruler's labels ran into one another, and the first one covered the unit. Major ticks were kept at least 70 px apart whatever their labels said, but the labels grow with the time and with the decimals a fine step needs: 10.8 s into a capture at 10 ns a division they read like 10.80115195, which is 69 px of text in the bundled 11 px IBM Plex Sans (figures 6.6 px, the point 3 px, measured in Chrome), 75 px with its padding. Whether a given zoom level lands in that range depends on the window width and display scaling, so it showed on some computers only.

• Space major ticks by the width of their labels: rulerTicks estimates the labels at both ends of the view and takes larger 1-2-5 steps until neighbouring labels keep 12 px of room. The overview strip shares the rule, and the time per division in the status bar follows the step (10 ns/div becomes 20 ns/div in the case above).
• Leave out a label near the ruler's left edge by where its text begins, not where its tick is, so long labels no longer cover the unit; the tick mark stays.
• Describe both in DESIGN.md §6.1.

Label widths are estimated from the bundled font's metrics (labelWidth in src/timeline/ticks.ts) rather than measured at run time; a change of the tick label font or size has to update them.

Validation:

• pnpm exec eslint src
• pnpm typecheck
• pnpm test: 86 files, 609 tests passed, including new cases in ticks.test.ts (the reported state: 10.8 s at 100 MHz, 71 px for 10 ns) and TimelineRuler.test.ts (a label at 40 px that would cover the unit), which fail on the previous code
• Not checked by hand in the running app: the demo device's captures are too short for labels this long; for labels up to about eight characters the steps are as before