Rebuild the Donor Recent activity panel (#358)

[2ndtlmining]

Closes #358.

Measured before anything was designed — 233 real transactions across three donor wallets in the live 7-day window:

category	count	share
Node rewards	219	94.0%
Transfers out	9	3.9%
Transfers in	4	1.7%
From Flux Foundation	1	0.4%
To Flux Foundation	0	0%
Exchange, either way	0	0%

Five of seven category lines were reserved for 2.1% of the data, three never fired at all, and the other 94% rendered as 219 identical unclickable rows.

Two bugs first, because the presentation sat on wrong numbers

walletTxFetch.js had no test file, which is how both survived.

The window was silently truncated. MAX_PAGES capped the scan at 100 transactions. A real 120-node wallet's 7-day window holds 803 across 82 pages — so the panel summarised 12% of it and called the result "net over 7 days". Understated, with nothing saying so, for exactly the operators with the most at stake.

Fetching 82 pages for one panel isn't affordable against this explorer, so the cap stays (25 pages) and a truncated scan now reports the span it actually covered. A smaller window honestly labelled beats a seven-day figure that's quietly an eighth of the truth.

The early break never fired. It tested the whole accumulated array, which keeps page 0's recent transactions forever — so it could only be true for a wallet with no activity. Precisely backwards: every active wallet paid the full budget however little it needed.

Then the panel

• Consecutive rewards collapse into one expandable entry. Verified live: 250 rewards became one line reading 250 node rewards +280.00, expanding to 250 rows.
• A per-day reward strip — 219 identical rows can't answer "am I still earning?"; a gap in the bars can.
• A category earns its line by having something in it. Node rewards stays at zero, because a donor earning nothing needs that stated, not inferred from an absent row.
• Every row reaches the explorer. Needed a new explorerAddressUrl with its own validator — a Flux address is a 35-character base58 t1/t3 string, not the 64-hex hash the other two take, so reusing that check would reject every real address.

Both Foundation rows gone, as reported

One receipt and zero sends in 233 transactions, and per #270 a payment to a Foundation address can't be told apart from an app deployment anyway. The amounts fold into transfers and the individual row keeps its "Flux Foundation" label — naming a counterparty is worth doing, a permanently-zero total isn't.

The deliberate loss: a donor's own donation lived in that row. It's already on Home's Community Support panel and the donor chip, and #270 puts a real App deployments row in that space.

Caught while verifying — same class of error this issue is about

With the scan truncated, the four days before the covered period drew as empty bars — saying the nodes stopped earning on days nobody looked at. Those are now hatched and labelled unknown. And when no day was fully covered the strip says nothing at all, so it's hidden rather than drawn as seven empty columns.

Testing

1,096 tests passing (46 new across walletTxFetch, walletActivityView and explorerLinks), yarn build clean with no new warnings.

Verified in a real container: truncation banner, hatched unscanned days, collapse/expand, explorer links resolving to /tx/<hash> with no /api/, and only non-zero categories rendering.

One caveat: the strip looks sparse in my screenshots because the explorer is rate-limiting this machine, which truncates the scan to a couple of days. On a healthy scan it fills out.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JuEXFs93A7ZKsGa5fEDceu