Per-pool share-warning toggle and aggregate large coinbase outputs

[warioishere]

I'm working on new minings modes for blitzpool (currently in testing) that pays miners directly via the coinbase tx — Group-Solo / PPLNS, with the share going straight to each miner's address instead of accumulating at the pool. Ocean is the only other pool I'm aware of that splits the reward across many outputs the same way. PPLNS is not the real intention to her but the Group-Solo Mode might be interessting for some group Pleb Miners that dont want to trust a single admin or a pair of admins managing a multisig wallet.

Two things break on the Bitaxe dashboard when mining on a pool like that:

• The "your share is only X%" warning fires on every block. It's literally correct, but on a direct-payout pool it's expected behaviour, not a problem.
• The decoder caps the output list at 6 entries. With 20–30 payout outputs in a single coinbase, the user's own output sometimes isn't even in the list.

This PR addresses both. Defaults are unchanged for normal solo / fee-based pools.

Share warning toggle

• New per-pool checkbox under Advanced Options → "Share Warning".
• Surfaced in /api/system/info as stratumShareWarning / fallbackStratumShareWarning.
• Default true, so existing users see no change.
• The dashboard's NOT_SOLO_MINING / NO_MINING_REWARD messages now check the active pool (primary vs fallback) and only fire if its toggle is on.

Larger output list with smart fill

• MAX_COINBASE_TX_OUTPUTS raised from 6 to 32.
• For txs with even more outputs, the decoder keeps the user's payout output and the highest-value entries; the rest is folded into a new "others" bucket (coinbaseOthersCount + coinbaseOthersValueSatoshis). OP_RETURN / witness commitment outputs are never evicted.
• Total and user-value sums are still computed across all outputs, so the share percentage stays accurate.

Dashboard changes

• The user's payout output is moved to the top of the list so it's always visible.
• The list is capped at 5 visible rows — anything beyond that is rolled into a + N other recipient(s) summary line with the aggregated value. Includes outputs that fit in the array but didn't make the visible cap, plus any server-side overflow from coinbaseOthersCount.

Things I'm happy to change if you want it different

• MAX = 32 is a round number that fits comfortably for the pools I know of. Could go higher or be made dynamic against PSRAM. Costs ~3.7 KB extra in GlobalState.
• Visible row cap = 5 was picked so the Block Header card stays compact. Could be 4, 6, or made configurable.
• I went with an explicit toggle because behaviour is predictable. An auto-detect ("more than N outputs and user is one of them → suppress") is also possible and would need no UI, but it's harder for the user to understand why the warning disappeared.
• Reordering the user output to the top applies to all pools, not just PPLNS. Small UX win in general; can be hidden behind the toggle or skipped if you'd rather keep TX order.

Builds fine.

[github-actions]

Test Results

  2 files  ±0    2 suites  ±0   1s ⏱️ ±0s
123 tests +2  123 ✅ +2  0 💤 ±0  0 ❌ ±0 
125 runs  +2  125 ✅ +2  0 💤 ±0  0 ❌ ±0 

Results for commit 54420fb. ± Comparison against base commit d3dbcc5.

♻️ This comment has been updated with latest results.

[mutatrum]

Screenshots please 🙂

[warioishere]

I also removed the red coloring when the share warning is disabled, and reduced MAX_COINBASE_TX_OUTPUTS back to 8, as we now only show 4 outputs and aggregated the rest so the card hight doesnt expand. Not sure if this is the best idea, maybe people want to see all outputs?

[mutatrum]

By having 2 separate max_item values the aggregation code is duplicated between frontend and backend. It's probably simpler to just keep it to the backend, at least for now. A cherry-on-top change would be to adjust the number of visible items on the frontend based on the size of the card, but that would be outside the scope of this PR.

[warioishere]

you are right, MAX_COINBASE_TX_OUTPUTS ist the single soure now.

[mutatrum]

Can you fix conflicts, please?

[warioishere]

conflicts fixed. hope its okay like that. reimplemented on top of the current PoolConfig array. the share warning is a field on PoolConfig, so it works for all pools, not just primary/fallback. MAX_COINBASE_TX_OUTPUTS stays at 6, aggregation only kicks in beyond that. stratum_v1_task.c and stratum_v2_task.c both carried the same coinbase → global-state block, so I folded it into a shared SYSTEM_update_coinbase_outputs() rather than writing the new aggregation twice.