fix(SDK-818): normalize className prop support across all SDK components

[dmortal]

Summary

CommonComponentInterface declares className?: string on every SDK component's props so partners can override the wrapper element's CSS class, but support was inconsistent — many components accepted the prop in their type while silently dropping it. This normalizes the contract across the SDK: a fresh, independently-verified audit of every component extending CommonComponentInterface/BaseComponentInterface found 54 non-compliant components; this PR fixes all of them (146 files touched total, including inner view/presentation layers and tests) and leaves the ~40 legitimate Flow-orchestrator exemptions (no single wrapper to attach a class to) untouched.

Landed as 6 commits grouped by domain (each independently reviewable):

• Company/Contractor
• Contractor/Employee (Compensation, Dashboard, Documents)
• Employee/InformationRequests/Payroll (Lists, Addresses, Terminations)
• Payroll off-cycle/transition creation
• Payroll PrintChecks/Overview/Receipts
• TimeOff

Each fix follows one of two established patterns already used elsewhere in the codebase:

• Same-file / forward: destructure className and apply it via classNames(styles.x, className) on the component's own wrapper, or forward it to an already-compliant child/primitive.
• Threaded: add className support to an inner *View/*Presentation component that previously had none, then thread it down from the outer component.

A regression test was added per fixed component, asserting the custom className reaches the rendered root (following the existing test convention used in Box.test.tsx / PayrollBlockerList.test.tsx).

Test plan

• Full suite: npm run test -- --run → 369 files / 4032 tests passing (1 pre-existing, unrelated expected-fail)
• npx tsc --noEmit clean
• eslint clean on all touched files (3 pre-existing, unrelated react-hooks/exhaustive-deps warnings confirmed present on main before this change)
• npm run build succeeds

🤖 Generated with Claude Code

[serikjensen]

Reviewed all 153 files with a focus on className application. The change is consistent and mechanical throughout. Each fix uses one of the established patterns:

• Forward to Flex (<Flex className={className} ...>, merged via classNames)
• Thread down to an inner *View/*Presentation component
• Merge onto an existing styled root (classNames(styles.container, className))
• Forward to a primitive that already accepts it (Form, HtmlForm, Alert, Select)
• New <section className={className}> wrapper where the component returns a fragment with a sibling Dialog/Modal

Every fixed component has a matching regression test asserting the class reaches the rendered root. No exceptions to the contract found.

Two trivial, non-blocking nits (not required to address):

• PayrollOverviewProps and PayrollReceiptsPresentationProps add className?: string without the /** CSS class name applied to the root element. */ doc comment used elsewhere. Both are @internal, so it's cosmetic.
• The <section> boundary differs slightly between the address views (modals inside) and the employee-list views (dialog outside), but this is irrelevant since dialogs render in portals.

LGTM.

---

Generated by Claude Code