Sepo-Ledger: Patch @ledgerhq/hw-app-eth for Arbitrum Sepolia chain id…

… handling (#3650)

It currently seems like there is an issue with Ledger's handling of high
chain ids for certain transactions, where the Ledger can provide a first
byte that breaks the expectations of the chain id adjustment done for
legacy transactions to conform to EIP-155. The resulting `v` value
returned from the signing flow is invalid and Ethers throws because of
this.

This fix *may* be correct, but it may not be. To adjust for this fact,
the patch limits adjustments of the underlying parity value in Ledger to
happen only when the chain id matches Arbitrum Sepolia's (412614), as
that's the only place we've seen consistent reports of the issue.

See also LedgerHQ/ledger-live#5265 .

Fixes #3647 .

## Testing

- Easiest way to test here is really to just hammer
https://app.taho.xyz/ . In reproducing, we've found that some
transactions trigger the issue and others don't, depending on what the
first byte of the Ledger response to the signing request is.

Latest build:
[extension-builds-3650](https://github.com/tahowallet/extension/suites/17798752935/artifacts/1021248068)
(as of Wed, 01 Nov 2023 09:45:37 GMT).

patches/@ledgerhq+hw-app-eth+6.33.4.patch

@@ -0,0 +1,13 @@
+diff --git a/node_modules/@ledgerhq/hw-app-eth/lib/Eth.js b/node_modules/@ledgerhq/hw-app-eth/lib/Eth.js
+index 4a7cb64..bd7051b 100644
+--- a/node_modules/@ledgerhq/hw-app-eth/lib/Eth.js
++++ b/node_modules/@ledgerhq/hw-app-eth/lib/Eth.js
+@@ -228,7 +228,7 @@ class Eth {
+                 }
+                 else {
+                     // Legacy type transaction with a big chain ID
+-                    v = chainId.times(2).plus(35).plus(ecc_parity).toString(16);
++                    v = chainId.times(2).plus(35).plus(chainIdTruncated === 412614 ? ecc_parity % 2 : ecc_parity).toString(16);
+                 }
+             }
+             else {