Unify pool configuration flows

[pavlenex]

This PR replaced the three separate custom-pool workflows from PR #217 with one shared pool configuration flow used by both Setup and Settings. Users can now add, remove, and reorder primary and fallback pools in the same interface. The primary payout address or username is entered once, while fallback pools inherit it automatically unless the user explicitly chooses to customize them.

This is better because there is now one consistent behavior to understand, test, and maintain instead of several implementations that could drift apart. It also reduces repetitive forms and excessive scrolling, preserves custom fallback identities safely, and validates pool configuration on both the client and server before saving.

I based it on #217 to preserve commit history and credit the author for the effort that inspired a more complex refactor. There's a lot here so no need to prio review, but whenever you get a chance @lucasbalieiro I'd appreciate if you have a better idea on how to architect this.

Screen.Recording.2026-07-17.at.14.55.02.mov

[Ayush4958]

@pavlenex
I really like this new architecture which removes dropdown select and introduce direct selection and customization.

really learned from it ...

[lucasbalieiro]

I first of all thank you guys. Seems like a nice and structured improvement.
I've did the fist round of reading the important code changes here. I'm gonna take a time now to do some testing locally

[pavlenex]

Thank you so much @lucasbalieiro! We depend on your reviews 🫂

[lucasbalieiro]

If you select multiple pools, set the SRI as primary and donate 100% the UI loses the information of the payout address that it asked and make me type the address for each one again.

that is expected because the UI is cleaning the address if you give 100% to SRI pool. but seems that a UI improvement could be preserving this data and apply to the pools that does not support our user_identity features of donation.

Screen.Recording.2026-07-20.at.15.19.41.mov

[lucasbalieiro]

when setting the donation to 100%, I can only go back to 0% or 100%, no mid value

Screen.Recording.2026-07-20.at.15.31.09.mov

[Ayush4958]

in src/lib/miningIdentity.ts

buildSriIdentity function drops the address from the encoded string when donation is 100%, present here :-

if (donationPercent >= 100) {
  return worker ? `sri/donate/${worker}` : 'sri/donate';
  //  address gets dropped
}

So when the user enter their address and sets donation to 100, the identity becomes just "sri/donate". Their entered address is dropped. So even after user sets back the donation to any range it gets called with empty address and had to enter the address again.

The slider only fixed to 0 and 100 is the consequence of it.

we can fix it modifying this buildSriIdentity function like that :-

 export function buildSriIdentity(address: string, workerName: string, donationPercent: number): string {
   const addr = address.trim();
   const worker = workerName.trim();
   if (donationPercent >= 100) {
    if (!addr && !worker) return 'sri/donate';
    if (!addr) return `sri/donate/${worker}`;
    return worker
      ? `sri/donate/100/${addr}/${worker}`
   : `sri/donate/100/${addr}`;
   }

This is after the fix :-

Screen.Recording.2026-07-21.012737.mp4

on 100, user cannot continue , It says it should be b/w 0-99
we can change with small tweak, If we had to change it

[Ayush4958]

Note :- This bug is not created in this PR, they were present already in the file but they were not exposed

[pavlenex]

@lucasbalieiro another nice catch, fixed via

Screen.Recording.2026-07-21.at.10.29.59.mov

b44fe34

[lucasbalieiro]

tACK looks very nice.

My concerned with loop useEffect was addressed when the useRef was addded in b44fe34

confirmed that the pool priority on the config file is correctly ordered after this refactor:

confirmed that after a modifying the pools list inside the dashboard settings, the changes are applied correctly after tis refactor

[pavlenex]

Thanks for review @lucasbalieiro I've just resolved conflicts introduced when we merged #219. I think this one should be good to go. Needs final approval.

[lucasbalieiro]

Did a quick check on the main points after the rebase and LGTM