ROHME-6: unbrick the fee pipeline — FeeCollector.setMaxHarvest(10 ROHM)

ROHME-6: unbrick the fee pipeline — FeeCollector.setMaxHarvest(10 ROHM) WHAT IS BROKEN. FeeCollector.harvest() has never successfully run. It currently holds about 674 ROHM of protocol fees - roughly 15 pct of supply - that cannot be converted to backing. Every keeper cycle since launch has logged the same revert: UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT WHY. _minWethOut derives the swap floor from the SPOT reserve ratio: minOut = amountIn * reserveWeth / reserveRohm * (1 - slippage) A constant-product swap can never return spot. It returns amountIn*997*reserveWeth / (reserveRohm*1000 + amountIn*997) so the floor ignores both the 0.30 pct pool fee and price impact entirely. Solving for when the swap can actually clear its own floor gives amountIn <= reserveRohm * (1000s - 3) / ((1 - s) * 997) Note the -3: at any slippage tolerance below 30 bps that expression is NEGATIVE, and no amount can ever clear a floor that does not even cover the pool fee. At the deployed 500 bps the ceiling is about 4.96 pct of the ROHM reserve - roughly 30.7 ROHM against a 500 ROHM cap. It is off by about 16x, which is why it has never once succeeded. THE FIX. 1. FeeCollector.setMaxHarvest(10000000000) (10 ROHM, 9-dec) 10 ROHM sits comfortably under the ~30.7 ROHM ceiling. The headroom is deliberate: the ceiling is a fraction of pool depth, so anyone can grief a harvest sitting near the edge by buying ROHM in the same block to shrink reserveRohm, at a cost of one 0.3 pct round trip. Three times headroom makes that uneconomic. WHAT HAPPENS AFTER. Each harvest sells ROHM into the pool, which raises reserveRohm and therefore raises the ceiling, so the process self-accelerates: draining the current balance takes roughly 16 calls rather than the ~67 a static estimate suggests. harvest() is permissionless, so the keeper resumes on its own with no further governance. Half of each conversion goes to the Treasury as pure backing (profit == value, so it mints ZERO ROHM) and half to the creator. WHAT THIS IS NOT. This is a parameter change that works around the defect; it does not fix it. The correct fix is to derive the floor from router.getAmountsOut() instead of spot, which needs a FeeCollector redeploy and a separate decree. Until then the cap must stay below the pool-depth ceiling, and it must be revisited if POL depth ever falls materially. This proposal supersedes part of the original ROHME-1, which bundled this with the Governor V2 migration under a single-line description. The migration is now ROHME-5.