DSCEngine has no reentrancy guard and violates CEI in redeem/liquidate, allowing a malicious collateral token to drain the protocol

Description

_redeem_collateral updates state, logs, then makes an external transfer to an arbitrary _to, with no reentrancy guard anywhere in the engine. If a collateral token has a transfer hook (ERC-777-style, or a malicious token the constructor accepted), the recipient re-enters during transfer.

liquidate (dsc_engine.vy:124-130) redeems collateral to msg.sender before burning the user's DSC, so the health-factor accounting is mid-update when the external transfer fires.

Risk

Likelihood:
Medium. Requires a collateral token with a callback. The two collateral tokens are fixed at deploy, but standard tokens like WBTC/WETH variants, rebasing/hook tokens, or a deliberately chosen token expose this.

Impact:
High. Re-entering redeem_collateral / liquidate before the burn completes lets an attacker pull collateral multiple times against one debt reduction, draining other users' deposits and rendering the protocol insolvent.

Proof of Concept

Deploy a collateral token whose transfer re-enters redeem_collateral.

Recommended Mitigation

Add Vyper's reentrancy guard to every state-changing external entrypoint.