Tabs: stop insetting a tab's content twice on the right

[JeanMarcMilletScality]

Do not merge yet. This is one half of an alignment change; on its own it makes a tab form's action buttons overhang its fields by the width of a scrollbar. The other half is undecided — see Follow-up.

TL;DR — Tabs: a tab's content was inset on the right twice when the content already had a gutter of its own, leaving a form's scrollbar floating in the middle of a gap instead of near the edge; the tab no longer adds that side.

Context / Why

TabContent insets its content by 1rem on all four sides. A tab-layout Form carries a right gutter of its own — its layout's padding-right plus the room reserved for its scrollbar — so on that side the two stack up.

🧩 Approach

// before
padding: 1rem;                 // ←

// after
padding: 1rem 0 1rem 1rem;     // ←

The right gutter belongs to whatever the tab renders, since only the content knows whether it has already paid for one. Left, top and bottom stay — nothing else supplies those.

What this changes for content that has no gutter of its own, which is the reason this is worth a look rather than a rubber stamp. Every <Tab> call site across the consuming applications:

	Call sites	Already pass withoutPadding
One application's identity surfaces	24	8
One application's monitoring panels	3	1
Everything else searched (six repos)	0	—

The nine that already opt out of padding entirely are unaffected. The remaining eighteen lose a 1rem right inset unless their content brings one — and none of them has a Form as its direct child: every one renders a repo-local wrapper component, so the change cannot be conditioned on what the child turns out to be.

That leaves two shapes for this, and this PR takes the first:

1. Make it the default, as here: the tab stops claiming a side it cannot reason about, and the ~18 call sites that want a right inset add one. Simple rule, some fallout to clean up in the consumers.
2. A per-Tab opt-in beside the existing withoutPadding, so nothing changes until a call site asks. No fallout, one more prop on an API whose padding story is already two props wide.

🔍 Review focus

• 🟡 Moderate — tabsv2/StyledTabs.ts › TabContent — every tab in every product renders through this. The blast radius is cosmetic and uniform (one edge, 1rem), but it is not zero, and option 2 above avoids it entirely.

🧪 How to test

1. Open a tab whose body is a layout={{ kind: 'tab' }} form.
2. The form's scrollbar should now sit near the tab's right border rather than a gap away from it.
3. Open a tab whose body is a plain block or table with no gutter of its own, and confirm whether losing the 1rem reads as wrong there. That judgement is what decides between the two options above.

Follow-up

• The other half of the alignment. With the doubled inset gone, a tab form's Cancel / Save / Delete row is left ending further right than the fields below it, by exactly the scrollbar's width. That row is not a scroll container, so scrollbar-gutter is inert on it, and the bar's width is a keyword rather than a length — there is no constant to compensate with. It has its own diagnosis and three candidate fixes, none chosen. This PR should not merge before that is settled, or the visible result is a worse misalignment than the one it fixes.

🔗 References

• Form: keep the content clear of the scrollbar in both layouts #1196 — reserved the scrollbar gutter inside the form's scroll area. That reserve is the right-side inset this change stops doubling.

---

🤖 Generated with Claude Code

[bert-e]

Hello jeanmarcmilletscality,

My role is to assist you with the merge of this
pull request. Please type @bert-e help to get information
on this process, or consult the user documentation.

Available options

name	description	privileged	authored
/after_pull_request	Wait for the given pull request id to be merged before continuing with the current one.
/bypass_author_approval	Bypass the pull request author's approval	⭐
/bypass_build_status	Bypass the build and test status	⭐
/bypass_commit_size	Bypass the check on the size of the changeset TBA	⭐
/bypass_incompatible_branch	Bypass the check on the source branch prefix	⭐
/bypass_jira_check	Bypass the Jira issue check	⭐
/bypass_peer_approval	Bypass the pull request peers' approval	⭐
/bypass_leader_approval	Bypass the pull request leaders' approval	⭐
/bypass_source_branch_lineage	Bypass the cross-branch contamination check	⭐
/approve	Instruct Bert-E that the author has approved the pull request.		✍️
/create_pull_requests	Allow the creation of integration pull requests.
/create_integration_branches	Allow the creation of integration branches.
/no_octopus	Prevent Wall-E from doing any octopus merge and use multiple consecutive merge instead
/unanimity	Change review acceptance criteria from one reviewer at least to all reviewers
/wait	Instruct Bert-E not to run until further notice.

Available commands

name	description	privileged
/help	Print Bert-E's manual in the pull request.
/status	Print Bert-E's current status in the pull request.
/clear	Remove all comments from Bert-E from the history TBA
/retry	Re-start a fresh build TBA
/build	Re-start a fresh build TBA
/force_reset	Delete integration branches & pull requests, and restart merge process from the beginning.
/reset	Try to remove integration branches unless there are commits on them which do not appear on the source branch.

Status report is not available.

[bert-e]

Waiting for approval

The following approvals are needed before I can proceed with the merge:

• the author

• one peer

Peer approvals must include at least 1 approval from the following list:

• @damiengillesscality

• @ChengYanJin

• @JeanMarcMilletScality

• @sanassicisse

• @JBWatenbergScality

• @hervedombya

• @PierreAlexandreDelgado

• @ZiyangLinScality

• @MonPote