Prop 68: Hold the M013 burn flat through the emissions cut: raise the burn share 15.0% -> 30.0%

I authored #66, the M013 burn pool, and #64 and #67 from this same address. This proposal exists because #67 has a cost I disclosed in it, and this is the fix for that cost. THE PROBLEM: #66 streams 15.0% of community-pool revenue to the null sink. That revenue is 17% of block rewards, so it scales directly with emissions. #67 (now in its voting period) halves emissions, which halves the burn as a side effect — from about 546,154 REGEN/yr (about $635) to about 273,077 REGEN/yr. The burn is not the reason to oppose #67 (net supply change improves far more than the burn loses), but losing half of a working deflation mechanism as collateral damage is not something to shrug at either. THE FIX: raise the share from 15.0% to 30.0%, a factor of 2.00x, so the burn keeps its throughput in REGEN/day even after emissions are cut. Taken together with #67 the result is: dilution roughly halves AND the burn program loses nothing. MECHANICS: x/protocolpool has no update-fund message, so this is two messages — MsgCancelContinuousFund then MsgCreateContinuousFund at the new share, both against the same null-sink recipient regen1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqvptr3e, both authorised by x/gov. Cosmos gov applies a proposal's messages atomically, so there is no state where the burn is cancelled and not recreated. Effective on pass, no chain upgrade, no new module, and cancellable or re-dialled at any time by a later proposal. This deliberately touches x/protocolpool and NOT x/mint, so it cannot interfere with #67 whichever order the two resolve in. WHAT IT COSTS, PLAINLY: the burn share comes out of the same pool that funds grants, so raising it leaves less for pool-funded work. Today the pool takes in about 3,641,026 REGEN/yr and about 3,094,872 REGEN/yr is available after the burn. At 30.0% that available figure becomes about 2,548,718 REGEN/yr before #67's halving, and roughly half that after it. Programs drawing on the pool — LiquidityDAO emissions transfers, the Tokenomics WG, the X-Influencers pilot, and any future pool-funded work including my own — are squeezed by this on top of #67. I would rather state that than have it found. If the community would rather protect grant capacity than burn throughput, vote this down and keep #67: #67 stands on its own and does not depend on this passing. WHY THE NULL SINK AND NOT A KEEPER: regen1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqvptr3e is 20 zero-bytes bech32-encoded, provably keyless, so REGEN sent there is permanently unspendable with no operator and no trust assumption. Honest scope, unchanged from #66: regen-1 has no supply-burn module, so this removes REGEN from CIRCULATION rather than reducing the total_supply metric. Verified live since #66 executed — the sink has been receiving every block. REPRODUCE: /cosmos/protocolpool/v1/continuous_funds, /cosmos/distribution/v1beta1/params, /cosmos/bank/v1beta1/balances/regen1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqvptr3e, /cosmos/mint/v1beta1/annual_provisions.