fix/rpu-12-digit

Block comment misattributes the defense-in-depth rationale to autofill/password-manager DOM writes

apps/platform/src/app/[locale]/(dashboard)/bills/_components/AddContractDrawer.tsx:147

The comment claims the cap guards against 'browser autofill, a password-manager/extension writing .value directly'. For a React controlled input, direct DOM .value writes do not update React state, and autofill fires a synthetic change event that goes through onChange (which already normalizes). The real rationale is defense-in-depth against internal programmatic setValue() calls that omit normalizeRpuInput — with the PDF-extraction path at line 365 being the canonical example. The comment should say: 'Defense-in-depth: value can be set programmatically (e.g. PDF extraction at line 365); the useMemo ensures the cap is enforced regardless of write path, so the lookup gate can never see >12 digits and hang on Verificando.'

PR description misquotes the prior regex as /D/g (missing backslash) — documentation artifact only

apps/platform/src/app/[locale]/(dashboard)/bills/_components/AddContractDrawer.tsx:151

The PR description's DIFF section shows the old line as value.replace(/D/g, '') (no backslash). Git history confirms the actual pre-commit code was value.replace(/\D/g, '') (correct non-digit strip). The code change itself is correct; this is a rendering/escaping artifact in the PR description only.

.slice(0, RPU_LENGTH) cap in useMemo is forward defense, not a fix for a current live bug

apps/platform/src/app/[locale]/(dashboard)/bills/_components/AddContractDrawer.tsx:151

All current setValue() call sites already pass through normalizeRpuInput (onChange line 426, PDF extraction line 365, reset line 136 sets ''). Under the current code, React state value can never hold more than 12 digits. The cap is legitimate defense-in-depth against a future setValue() call that omits normalization — no action required; noting for clarity.

extractServerErrorMessage passes arbitrary server-controlled strings verbatim to toast UI

apps/platform/src/app/[locale]/(dashboard)/bills/_lib/rpu-errors.ts:39

The function extracts body.data.message, a Zod-issue message, or body.message from the server response and passes it as the toast description prop without any length cap or allowlist. React renders it as a text node so XSS is not exploitable under the current rendering model, but a compromised or misconfigured API endpoint could surface arbitrary strings in the UI. Defense-in-depth would be a max-length cap (e.g. 200 chars) or a map of known error tags to localized strings. Pre-existing issue, not introduced by this commit.

No component-level regression test for >12-digit value being capped by useMemo

apps/platform/src/app/[locale]/(dashboard)/bills/_components/__tests__/AddContractDrawer.rpuGate.test.tsx:69

The pure-function cap is covered in rpu-errors.test.ts, but no component-level test exercises the specific regression this commit closes: a value state holding >12 digits (e.g. via a future un-normalized setValue call) should still produce digits.length === 12 and not leave the drawer stuck on 'Verificando…'. A single fireEvent.change with a 14+ digit string asserting the create form remains available would close this gap and make the intent auditable.