[Bug]: Received and Confirmed Custom Nonce is Ignored by the Transaction Constructor

### Describe the bug

When developing a dApp that's intended to cancel pending transactions, I observed an inconsistency in MetaMask's UI behavior, particularly concerning nonce reuse. I wish to highlight a specific anomaly for this report.

### Steps to reproduce

1. Create a transaction, either manually or using a script, with the following configuration:

```
gas: 23000n,
maxFeePerGas: parseEther('1', 'gwei'), // Set gas to 1 gwei (This will ensure the transaction isn't processed quickly. If it does process quickly, retry when gas is greater than 5, for instance.)
maxPriorityFeePerGas: parseEther('0.000000001', 'gwei'), // 1 wei is the minimum acceptable value for this parameter.
```

This transaction, once submitted, should remain in the PENDING state within the mempool queue.

2. Now, attempt to override (or replace) the pending transaction using a script (e.g., ethers). Assume that the nonce is '13'. Use this configuration:

```
gas: 23000n,
maxFeePerGas: parseEther('1.1', 'gwei'), // pending tx gas plus 10%
maxPriorityFeePerGas: parseEther('0.000000002', 'gwei'), //pending tx priority fee plus 10%, since is wei value, we must rund up
nonce: 13, // This assumes the nonce of the current pending transaction is 13, if not change to your pending nonce.
```

3. The observed result and discrepancy can be seen in the provided screenshot:

- A custom nonce (in this case, '13') is set for the transaction.
- This nonce is recognized and confirmed by MetaMask's UI.
- However, the transaction constructor at the bottom ignores the custom nonce.
- Consequently, if we dispatch the transaction via MetaMask, it adopts a new nonce (e.g., '14'), which was not the intended behavior.

Note: Manually entering the nonce value ('13') in the bottom section facilitates the desired transaction flow, successfully replacing the earlier one. This indicates that there isn't an inherent "correction" occurring for an erroneous nonce. The issue appears to stem from a partial UI integration lapse during transaction formulation or dispatch.

### Error messages or log output

```shell
There aren't explicit error messages, just the deviation from the expected behavior as detailed above.
```

### Version

10.35.1

### Build type

None

### Browser

Chrome, Firefox, Brave

### Operating system

Windows, MacOS, Linux

### Hardware wallet

_No response_

### Additional context

There are several other issues pertaining to pending transactions and their overrides. I plan to file separate reports for each to ensure clarity and specificity. There seems to be a notable misalignment between the expected behavior, as dictated by the MetaMask interface, and the actual outcomes experienced by users. This particular bug report is one manifestation of that broader pattern of discrepancies.

Start by reproducing the pending-transaction replacement flow described in the issue with MetaMask version 10.35.1, then trace how the confirmed custom nonce moves into transaction construction and dispatch. Done means the replacement transaction uses the supplied nonce rather than assigning a new one, and the existing pending transaction is replaced.

Written by the indexing model from the issue text.