fix: filter a fake ETH token from the balance list too (closes #235)

README.md

@@ -229,6 +229,7 @@ src/
     prices.js         — ETH/USD and token/USD via CoinDesk API
     scamlist.js       — known fraud contract addresses
     state.js          — persisted state (extension storage)
+    symbolSpoof.js    — the known-symbol spoof rule, shared by all surfaces
     tokenList.js      — top ERC-20 tokens by market cap (hardcoded)
     transactions.js   — tx history fetching + anti-poisoning filters
     uniswap.js        — Uniswap Universal Router calldata decoder
@@ -458,11 +459,12 @@ Which tokens an address shows is decided by `fetchTokenBalances()` in
 tokens do appear without the user adding them. An ERC-20 is shown when its
 balance is nonzero and it is in the bundled known-token list, is tracked by the
 user, or has 1,000 or more holders; a token claiming a symbol from the bundled
-list from any other contract address is always dropped. That filter is
-unconditional — the "Hide tokens with fewer than 1,000 holders" setting governs
-the transaction history and the send-screen token selector, not this list.
-Tracked tokens with a zero balance are listed as well while "Show tracked tokens
-with zero balance" is on.
+list from any other contract address is always dropped, and so is any token
+claiming a symbol that belongs to the native asset and therefore has no
+legitimate contract at all (`"ETH"`). That filter is unconditional — the "Hide
+tokens with fewer than 1,000 holders" setting governs the transaction history
+and the send-screen token selector, not this list. Tracked tokens with a zero
+balance are listed as well while "Show tracked tokens with zero balance" is on.
 
 #### Navigation
 
@@ -1280,14 +1282,15 @@ indexes it as a real token transfer.
   that is the only thing that populates it. In the transaction history the check
   is the "Hide fake tokens impersonating a known symbol" setting, on by default;
   with it off, spoofed transfers are shown and no new blocklist entries are
-  learned from them. The send-screen token selector applies the same check
-  unconditionally, because it decides which tokens the user can act on rather
-  than what the history displays. The balance list applies it unconditionally
-  too, but not identically: it exempts symbols that `KNOWN_SYMBOLS` maps to
-  `null`, and `"ETH"` is the only one. So the fake "Ethereum" token above is
-  filtered from the transaction history and from the send selector, but a
-  fake-`ETH` ERC-20 that clears the balance list's own 1,000-holder floor — or
-  that the user tracked manually — is still shown in the balance list.
+  learned from them. The send-screen token selector and the balance list apply
+  the same check unconditionally, because they decide which tokens the user can
+  act on and what the user believes they own rather than what the history
+  displays. All three surfaces read the rule from `src/shared/symbolSpoof.js`,
+  so they cannot answer the question differently. A symbol the list maps to no
+  contract at all — `"ETH"`, the native asset, is the only one — may be borne by
+  no contract, so every ERC-20 claiming it is a spoof on all three. The user's
+  real ETH balance is not an ERC-20 and is read over RPC, so the rule never sees
+  it.
 
 - **Low-holder token filtering**: Token transfers from ERC-20 contracts with
   fewer than 1,000 holders are hidden from transaction history by default.
@@ -1323,13 +1326,12 @@ indexes it as a real token transfer.
   a sharp tool — users who understand the risks can configure the wallet to show
   everything unfiltered, unix-style. All four settings govern the transaction
   history; what else each one reaches varies. The known-symbol check also runs
-  unconditionally on the send-screen token selector, and on the balance list
-  except for symbols mapped to `null` (`"ETH"` alone), which the balance list
-  does not filter. The fraud contract blocklist is applied unconditionally on
-  that selector and is not consulted by the balance list at all. The low-holder
-  setting also gates the send selector, while the balance list's own
-  1,000-holder floor is unconditional (see Data Model). The dust threshold
-  applies to the transaction history alone.
+  unconditionally on the send-screen token selector and on the balance list, in
+  both cases identically to the history. The fraud contract blocklist is applied
+  unconditionally on that selector and is not consulted by the balance list at
+  all. The low-holder setting also gates the send selector, while the balance
+  list's own 1,000-holder floor is unconditional (see Data Model). The dust
+  threshold applies to the transaction history alone.
 
 #### Phishing Domain Protection