fix: give every address a row of its own, so none wraps or is shortened (closes #380)

The wallet list was the reported case. An address there shared one row with
the [info] and [x] controls, which took about a third of the width off it,
so all 42 characters folded onto a second line. A folded address is not a
cosmetic problem: it turns one string the user is meant to compare against
a known value into two shorter ones, which is the shape an address-poisoning
attack wants.

The fix is the layout, not the CSS. renderAddressHtml() -- the single
renderer behind every common view that shows an address -- now emits an
identity strip (colour dot, wallet title, explorer link, with the ENS name
below it) and then the address alone on a full-width row. The wallet list
moves [info] and [x] up onto the "Address N" line, which was empty to its
right. The transaction rows on Home, the address screen and the token screen
carried a truncateMiddle()d counterparty squeezed in beside the amount;
they now name it on the amount line where we know it, and carry the whole
address on the row below.

With the row to itself, an address fits at every nesting depth the popup
uses, including the transaction detail wells, which are the narrowest
containers it has. .am-address holds nowrap so it cannot fold again, and
overflow-x so that if it ever does not fit -- wider glyphs, a zoom -- the
user can still reach the last character rather than having it clipped away
by #app's overflow-x-hidden with nothing to say it happened.

No caller passes maxLen any more, so the 32-character floor that lived in
those call sites moved into renderAddressHtml(). truncateMiddle() and its
10-character cap are unchanged: the guarantee has to outlive having no
current callers.

tests/e2e measures it in a real Chromium rather than asserting on markup:
whether an address wrapped is a question about glyph advances and the width
of the box it landed in, and nothing in the HTML answers it. Every rendered
address is checked for being whole, occupying one line box, fitting its row
and ending inside the popup's content box, with the document itself not
scrolling sideways -- across Home with a two-address wallet, the address,
token, receive, send and transaction detail screens, the confirmation screen
and the dApp transaction prompt.

README.md

@@ -800,7 +800,12 @@ discoverable.
   addresses visually, as a security feature.
 - **Tailwind CSS**: Utility-first CSS via Tailwind. No custom CSS classes for
   styling. Tailwind is configured with a minimal monochrome palette. This keeps
-  the styling co-located with the markup and eliminates CSS file management.
+  the styling co-located with the markup and eliminates CSS file management. The
+  handful of classes in `styles/main.css` are not styling: `.copy-flash-*`
+  carries the copy feedback animation, and `.am-address` carries the rule that
+  an address never wraps. Both are invariants that hold in every place they
+  appear, and spelling either out as repeated utilities is how one of those
+  places drifts away from the rest.
 - **Vanilla JS**: No framework (React, Vue, Svelte, etc.). The popup UI is small
   enough that vanilla JS with simple view switching is sufficient. A framework
   would add bundle size, build complexity, and attack surface for no benefit at
@@ -849,6 +854,12 @@ that the portions still displayed will be more than adequate for the user to
 verify addresses even in the case of address spoofing attacks. Clicking an
 address will always copy the full, untruncated value.
 
+As of the address-row layout change, no view invokes that exception: every
+address in the popup is rendered on a row of its own, wide enough for all 42
+characters, and no screen truncates one to fit. The cap is still enforced in
+`truncateMiddle()` and the 32-character floor in `renderAddressHtml()`, so the
+guarantee holds for any future caller; there simply are none today.
+
 **Specific Exception — Transaction Detail view:** The transaction detail screen
 is the authoritative record of a specific transaction and shows the exact,
 untruncated amount with all meaningful decimal places (e.g. "0.00498824598498216
@@ -1182,13 +1193,17 @@ view would leave a wallet one click from deletion.
     - Send / Receive quick-action buttons, both acting on the active address
     - ETH/USD price display
     - Wallet list: each wallet shows its name (tap to rename inline) and a "+"
-      button for HD and xprv wallets, then one block per address with "Address
-      N" (bold when active), the ENS name if resolved, the full address, an
-      `[info]` button, an `[x]` button (only on HD and xprv wallets holding more
-      than one address), the address USD total, and a balance line for ETH and
-      for each token shown for that address
+      button for HD and xprv wallets, then one block per address. The block
+      opens with a row carrying the colour dot, "Address N" (bold when active),
+      an `[info]` button and an `[x]` button (only on HD and xprv wallets
+      holding more than one address); the ENS name, if resolved, is below it;
+      then the full address on a row of its own, followed by the address USD
+      total and a balance line for ETH and for each token shown for that address
     - "Recent Transactions": up to 25 transactions merged across every address
-      of every wallet, deduplicated by hash and filtered
+      of every wallet, deduplicated by hash and filtered. Each row is three
+      lines: age and direction, then the counterparty's colour dot (with our own
+      name for it, where it is one of our addresses) and the amount, then the
+      counterparty's full address on a row of its own
     - "Add additional wallet..." link at bottom
 - **Transitions**:
     - Tap address row → sets the active address and broadcasts