fix: replace toWei with parseAmountToWei on the proposal form

toWei (utils/web3.ts) and parseAmountToWei (added in #738) do the same job, and the older one carries the crash the newer one exists to prevent.

pages/treasury/create-proposal.tsx:122 calls toWei(lptAmount) inside a useMemo, so a throw takes the page down:

const [lptAmount, setLptAmount] = useState(0);
onChange={(e) => setLptAmount(parseFloat(e.target.value))}
...
args: [lptReceiver, toWei(lptAmount)],

toWei is parseEther(ether.toString()), and Number.toString() emits exponent notation below 1e-6 and at/above 1e21, which parseEther rejects. So 0.0000001 becomes "1e-7" and throws — no e typed by the user.

Reproduction: enter a valid receiver address, then 0.0000001 as the amount.

Low likelihood — the field is min="1" and the page is gated behind 100 LPT staked — but it is reachable, and it is the last caller of toWei.

Fix

Keep the raw input string rather than parseFloat, and parse with parseAmountToWei:

const [lptAmount, setLptAmount] = useState("");
onChange={(e) => setLptAmount(e.target.value)}

const amountWei = parseAmountToWei(lptAmount);
if (!isAddress(lptReceiver) || !amountWei) return null;
args: [lptReceiver, amountWei],

toWei then has no callers and can be removed along with its two assertions in utils/web3.test.ts.

Caveat

This produces transaction calldata for a treasury transfer, so it warrants a test table pinning the encoding (1, 2.5, 0.1, 1000000, 0.000001) before and after. For every value the field can currently produce the encoded wei is identical — the paths only diverge where the current one throws — but that should be enforced by a test rather than by review.

Start with pages/treasury/create-proposal.tsx and utils/web3.ts, then inspect utils/web3.test.ts and the existing parseAmountToWei implementation. Verify the proposal form preserves raw input, uses parseAmountToWei, removes the unused toWei assertions, and add a table test covering the listed amounts and their transaction encoding.