Coarse-grained emergency mode forces all position exits through liquidation path, causing users to pay unwarranted liquidation fees

During emergency mode, closePosition, finalizeClose, and requestClose are all blocked by whenNotEmergencyOnly. However, liquidatePosition and finalizeLiquidate remain available. This means the only exit path for positions during an emergency (besides settlement, which requires market resolution) is liquidation, which charges liquidationFeeBps on the full notional (up to 20% max). The normal close path charges no liquidation fee.

The emergency admin (hot wallet) can enable emergency mode, but only the global admin (cold multisig) can disable it. If the multisig is slow to coordinate, the emergency window could extend for hours or days. Every position exited during that window pays a liquidation fee that would not apply under normal close operations, even if the position is perfectly healthy.

Consider a more granular emergency pause architecture, for example, a separate modifier for withdrawal/close operations distinct from whenNotEmergencyOnly. This would allow the admin to selectively block the close path only when the emergency specifically concerns close logic, while keeping it available when the emergency relates to other operations (e.g., position opening, market interactions). The existing three-tier pause structure (newPositionsPaused, userActionsPaused, serverHalted) plus emergencyOnlyMode could be extended with a withdrawal-specific tier.

Acknowledged. Emergency mode is the "risk-reduction only" tier by design; settlePosition and forceUnwind remain available with no liquidation fee.