Add a currency/amount input component with proper decimal handling

[Codex723]

Summary

Audit amount inputs across send/page.tsx and rates/page.tsx for floating-point precision bugs; consider a shared component using integer minor-units internally.

Difficulty

Intermediate — estimated effort: ~1-2 days. Labels: frontend, bug, intermediate

Where to Work

• send/page.tsx
• rates/page.tsx

How to Approach This

1. Locate the relevant page under src/app/(app)/ or component under src/components/.
2. Match the existing Tailwind utility-class conventions already used in that file — don't introduce a new styling approach.
3. If adding new interactive state, prefer local useState/useEffect consistent with how nearby components in the file already manage state.
4. Test the change at both desktop and mobile breakpoints (e.g. Chrome DevTools responsive mode) before opening a PR.
5. Run npm run lint and npm run build locally to confirm no type or lint errors were introduced.
6. If you added a new reusable piece of UI, consider whether it belongs in src/components/ instead of being page-local.

Acceptance Criteria

• Behavior/UI described above is implemented in the file(s) listed under "Files Likely Affected".
• Verified visually at both desktop and mobile widths.
• Keyboard accessible where interactive (tab order, visible focus state) if applicable.
• No new TypeScript, lint, or build errors (npm run lint, npm run build).
• Existing tests still pass; new tests added if this issue includes a testing component.

Notes for Contributors

Comment on this issue before starting so it can be assigned to you and duplicate work is avoided. If the described approach doesn't quite fit once you're in the code (e.g. the file has moved, or there's a cleaner way to do it), that's fine — leave a comment explaining the deviation in your PR description rather than silently changing scope.

[Vyacheslav-Tomashevskiy]

Picking this up. Scoping note: rather than a full new visual input component (which would mean reworking send/page.tsx's existing Tailwind layout more than this fix needs), I'm adding a small src/lib/currency.ts utility that does all amount math in integer minor-units (avoiding float-multiplication drift like 0.1*3=0.30000000000000004) and wiring send/page.tsx's amount input + conversion display through it, plus sanitizing the raw input so things like scientific notation or more than 2 decimal places can't reach the API payload. rates/page.tsx is read-only display of server-provided numbers (no user amount input), so there is nothing to fix there specifically - noting that as the deviation from the issue text. PR incoming.

[Vyacheslav-Tomashevskiy]

PR is up: #545 — /claim

Summary of what landed and how it was checked:

• New src/lib/currency.ts (toMinorUnits / fromMinorUnits / convertMinorUnits / sanitizeAmountInput) keeps the send amount as an exact integer count of minor units, converting the decimal string by string manipulation rather than parseFloat, so neither the amount nor the displayed conversion picks up binary rounding error.
• send/page.tsx routes the amount, the conversion display, the summary card and the continue-gate through it; the amount field is now type="text" + inputMode="decimal" + aria-label (type="number" also accepts scientific notation, so its value could disagree with what the user typed).
• 32 new unit tests, all green. eslint clean. npm run build compiles and type-checks this PR's code.
• Verified live at 1440×900 and 375×812: typing 12ab.3456e7 yields 12.34; element geometry at 375px is identical to main.

Two things worth flagging for review, both already in the PR description:

1. I implemented shared logic rather than a shared visual component, and left rates/page.tsx alone because it has no user-entered amount (all parseFloats there are read-only display of server-provided strings). Say the word if you'd rather have an actual <AmountInput> component and I'll extend it.
2. npm run build's TypeScript stage still stops on the pre-existing missing isValidStellarPublicKey import in src/lib/validations.ts — unrelated to this change, and what fix(validations): restore broken isValidStellarPublicKey import; feat: add /api/stellar/fee-estimate #529 fixes. Any PR opened against current main will hit it, so that one is worth merging first.