[material-ui][Tabs] Respect scroll-padding when scrolling the selected tab into view

[crispinc-omnea]

• I have followed (at least) the PR section of the contributing guide.

Problem

Tabs scrolls the selected tab into view with its own arithmetic. It compares the tab's getBoundingClientRect() with the scroller's, and it stops when the two edges meet. It does not read scroll-padding on the scroller.

scroll-padding is the CSS property for a scrollport that is partly covered by other content. Native scrollIntoView() respects it. Tabs does not.

This matters when the scroll buttons are positioned over the strip instead of beside it. The selected tab then stops under the button, and the end of its label is hidden.

Reproduction: https://aonizparxqgithub-mhof--5173--017acfb7.local-credentialless.webcontainer.io/
Issue: #49038

Change

scrollSelectedIntoView now reads scroll-padding on the scroller and keeps the tab inside it:

• On the start side it reads scroll-padding-left (scroll-padding-top when vertical).
• On the end side it reads scroll-padding-right (scroll-padding-bottom when vertical).
• A <length> is used as is. A <percentage> is resolved against the scroller's clientWidth (clientHeight when vertical). auto resolves to 0.

When no scroll-padding is set, both values are 0 and the arithmetic is the same as before. There is no API change.

Tests

New cases in Tabs.test.js:

• should account for scroll-padding-left when scrolling a tab into view on the left
• should account for scroll-padding-right when scrolling a tab into view on the right
• should resolve a percentage scroll-padding against the scroller clientWidth
• should account for scroll-padding-bottom when scrolling a vertical tab into view

All four assert the final scrollLeft / scrollTop. They pass in the jsdom project and in the browser project (Chromium).

Notes for reviewers

• The change is one getComputedStyle call per selection change. Nothing runs per frame.
• The start and end sides read the physical longhands, to match the physical left / right that scrollSelectedIntoView already uses.
• The comparison keeps the existing border-box rect of the scroller. With no scroll-padding set, the arithmetic is bit-identical to before.
• Known limit: a calc() value computes to a string that parseFloat cannot read, so it resolves to 0. This is the pre-fix behaviour, not a wrong scroll.
• The same fix applies to v7.x; a cherry-pick would be welcome.

[code-infra-dashboard]

Deploy preview

https://deploy-preview-49039--material-ui.netlify.app/

Bundle size

Bundle	Parsed size	Gzip size
@mui/material	🔺+276B(+0.05%)	🔺+115B(+0.08%)
@mui/lab	0B(0.00%)	0B(0.00%)
@mui/private-theming	0B(0.00%)	0B(0.00%)
@mui/system	0B(0.00%)	0B(0.00%)
@mui/utils	0B(0.00%)	0B(0.00%)

Details of bundle changes

---

Check out the code infra dashboard for more information about this PR.

[crispinc-omnea]

Could this also please be cherry-picked for v7?