refactor: simplify FlowALPRebalancerPaidv1

[holyfuchs]

Removes per-rebalancer RecurringConfig storage and the RebalancerPaid handle resource.
All PositionRebalancer instances now read from a single defaultRecurringConfig set by the admin, eliminating per-position config.
createPaidRebalancer is now fire-and-forget (no return value), and removal goes through Admin.removePaidRebalancer.
Focus on simplicity.

[jordanschalm]

Haven't finished the review, but I have a general question about the rebalancer design. From past Q&As I thought we needed an architecture where a single supervisor would check position health and only schedule per-position rebalances for positions that need it (are outside the health bounds). One rebalancer per position, all independently checking health and rebalancing at the same interval does not seem like it would scale to large numbers of positions.

Mainly want to confirm my understanding; if the plan is to make this change later, that's fine.

[holyfuchs]

Haven't finished the review, but I have a general question about the rebalancer design. From past Q&As I thought we needed an architecture where a single supervisor would check position health and only schedule per-position rebalances for positions that need it (are outside the health bounds). One rebalancer per position, all independently checking health and rebalancing at the same interval does not seem like it would scale to large numbers of positions.

Mainly want to confirm my understanding; if the plan is to make this change later, that's fine.

We initially discussed the current approach. The code is still from that time. It will certainly be more expensive to scale this.
Not sure if we want to change this.