[Bug]: Advanced gas editing input precision

Nobody has claimed this yet.

**Describe the bug**

Advanced gas is denoted in GWEI and as such it should be impossible to submit a value less than 0.000000000 (0 WEI) when paying gas in ETH. However, the input field lacks appropriate validation and allows a user to save unacceptable values between 10 and 17 decimal places beyond 0 GWEI. (a)

The UI is also misleading in that when gas less than 1 WEI is offered, the estimated gas shown on confirmation does not match what gets broadcast (shown in recordings a & d). I also notice that if the gas offering is less than 1000 WEI it will be represented in scientific notation if the user goes back to review through the edit link after initially saving. (b)

There also seems to be rounding when a value is less than 1 WEI, such that that .99 WEI is will be rounded up to 1 WEI when the transaction is submitted. (c)

In the event that a user attempts to offer 17+ decimal positions after 0, the input box is reset when the 18th character after decimal is entered.(d)

**Expected behavior**

User should see an error and not be able to proceed if they attempt to offer less than 0 WEI (0.0000000000+ ten positions or more beyond 0)
User should not see gas values presented in scientific notation
User should be presented a gas estimate that matches what they authorized after using advanced gas, in the confirmation.

**Screenshots/Recordings**

8a. Offering less than 1 WEI (.00077 WEI keyed in as 0.00000000000077 GWEI) truncates values to 0 contrary to subsequent UI presentation: https://recordit.co/zU6smrP7aM
8b. Offering 3 WEI max (0.000000003) presents in scientific notation: https://recordit.co/hDurLwjDpy
8c. Offering 0.00000000099 max priority fee (.99 WEI) is rounded up to 1 WEI when submitted to network, even though activity details show gas being offered at 0 and confirmation screen showed 0.0000315 Sepolia ETH: https://recordit.co/e7bj2mJpXn
8d. Attempting to supply a value more than 17 decimal positions beyond 0 results in the input field resetting IN this video I typed 0.000000000000000009, but the 9 reset the field resulting in a value of 0 being saved: https://recordit.co/0lwwQZDCfO

**Steps to reproduce**

All the steps are the same for each of the 4 observations here, and only step 8 changes slightly with each variation-

1. Have a wallet setup and access to an address with testnet funds (sepolia in my recordings)
2. Tap send from wallet view
3. Enter destination address
4. Enter amount
5. Tap `Next`
6. On confirmation screen tap `Market`
7. Tap `Advanced`
8. a. Key in values less than 1 WEI (0.00000000000077 GWEI Max base fee and 0.00000000000066 Priority fee) b. Offer gas less than 1000 WEI (<0.0000000x) c. Offer less than 1 WEI values with Max base fee value of 0.00000000099 and Priority fee 0.00000000088 d. Offer 0.000000000000000009 Max base fee and same for priority fee
9. Tap `Save`
10. Note that confirmation screen may not match what was entered (8a and 8d present 0.0000315 Sepolia Eth)
11. Tap `edit` to review the submission
12. Note that 8a/d presents Priority fee `0` and Max base fee of `1.500000013` now in details, 8b shows values in scientific notation
13. Tap `X` to close and not save over values
14. Tap `Confirm`
15. Note that pending tx details reflect 0 gas offered, truncating the values supplied by the user

**Version**

11.4.0

**Build type**

None

**Browser**

Chrome

**Operating system**

MacOS

**Additional context**

This was initially observed in 11.4.0 RC commit 6723b69a074c6d1efb02948c0639041d8211891c, but confirmed in both 11.2.0 and 11.3.0 in chrome 117 on Mac Sonoma 14.0 while using Sepolia testnet.

Start by reproducing the advanced gas flow in the send confirmation, including Save, edit, and Confirm, using the four values described in step 8. Trace how the entered values are validated, formatted, displayed in confirmation and activity details, and submitted; done means invalid sub-wei values are rejected, ordinary decimal values are preserved without scientific notation, and the confirmed estimate matches the broadcast transaction.

Written by the indexing model from the issue text.