feat(Payroll): add regular-rate-of-pay workweek distribution helpers

[krisxcrash]

Summary

• SDK-1135, the follow-up named in feat(Payroll): redesign Edit payroll UI as card/table sections #2467 (SDK-1134): "The per-workweek hours/earnings split (Regular Rate of Pay) stays in the design prototype and is tracked as separate follow-up work." This is that follow-up.
• Draft PR — blocked on the Embedded API. The fields this feature needs (per-earning "included in overtime pay," and workweek boundary data) do not exist in any released API version yet. They are actively being built in zenpayroll's embedded/partner API (tracked as EMBPAY-705 "workweek start day" and EMBPAY-709 "workweek breakdowns," commits as recent as this week), but are gated behind an internal alpha API version and an inactive company-level release flag — not reachable by this SDK's vendored API version or any real partner today. No UI or real API call is wired up here; that's blocked until the API ships.
• Adds src/components/Payroll/Rrop/rropHelpers.ts: a pure, framework-agnostic TypeScript port of gusto-web's evenlyDistributeValue (workweek-weighted pro-ration with rounding-remainder reconciliation onto the first workweek) plus needsWorkweekBreakdown/needsWorkweekBreakdownForEarning existence-based detection predicates, ported from gusto-web's useEmployeesNeedWorkweekBreakdowns.
• Workweek boundaries are accepted as an external { startDate, endDate }[] input, never derived client-side. Once the API ships, boundaries are expected to arrive as start_date/end_date on each compensation's breakdowns[] rows (from payrolls#prepare/#update/#create), not as a standalone workweeks list — a future integration ticket will extract a Workweek[] from that shape.
• Rounding precision is caller-supplied, since gusto-web itself uses two different precision conventions (2 vs. 6) in different code paths for the same math.
• One intentional deviation from gusto-web: an empty workweeks array returns {} here instead of throwing (gusto-web's real code throws on workweeks[0] before its own length check).

Known gaps / open questions (tracked, not resolved, in this PR)

• Mid-pay-period termination/rehire behavior is undocumented in gusto-web's and zenpayroll's test suites.
• Off-cycle payrolls covering employees with divergent workweek start days: zenpayroll's backend deliberately returns an empty workweek list rather than resolving this; this SDK inherits that limitation by construction.
• includedInRegularRateOfPay (gusto-web) vs. included_in_overtime_pay (proposed API) — naming/semantic equivalence is unconfirmed; the new predicate's parameter is named generically to avoid committing to either.
• Missed-break/break-premium support exists in gusto-web today but is entirely absent from the API work in progress.

Test plan

• npm run test -- --run src/components/Payroll/Rrop — 32/32 passing, covering the worked examples (equal/uneven/three-way splits, non-contiguous "gappy" workweeks, empty array, single workweek, remainder-to-first-week assignment, a precision 0–6 sweep, and a US DST-transition case)
• npm run test -- --run (full suite, on top of the rebased base branch) — passing
• npx tsc --noEmit and npx eslint clean on changed files
• No UI, i18n, or public API surface changes

🤖 Generated with Claude Code

[serikjensen]

This PR likely isn't needed. I tested it against staging (RRoP flag on) using the test fest's worked example: one Nonexempt employee, $22/hr, 80 regular hours, 5 overtime hours, $200 commission, biweekly period with two workweeks.

I ran the same payroll two ways:

	Overtime line	Gross pay	Breakdowns sent
No breakdowns	$170.88	$2130.88	none
Explicit breakdowns	$170.56	$2130.56	5 OT hrs in week 1

The key result: with no breakdowns at all, the backend still computed a correct Regular Rate of Pay premium ($170.88, not the flat 1.5x of $165). It does this by evenly spreading each total across the pay period on its own, then splitting by workweek.

That's the exact same even split this PR's evenlyDistributeValue does on the client. So sending its output as breakdowns just reproduces what the backend already does for free.

The small $0.32 gap is only because the 5 OT hours actually landed in week 1, not spread evenly. Closing that gap needs the employee's real per-week hours. This helper doesn't have those; it takes one pay-period total and splits it evenly, so it can never do better than the backend's own even split.

Conclusion: client-side distribution adds no accuracy over the backend. The helper is redundant unless we start collecting true per-week actuals from partners.

One side note: the breakdown-write request returned a 500 once, then succeeded on retry. Worth a look separately.

Posted by Claude on behalf of Steve

[serikjensen]

This one is already taken care of on the backend. see report here #2473 (comment) Closing for now