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