feat: add resend msg feature changes on fmas

security/fma-message-passing-contracts.md

@@ -63,17 +63,22 @@ Below are references for this project:
 - **Detection:** Monitoring tools should track every validated message to ensure it was observed and validated at the origin chain.
 - **Recovery Path(s):** The chain will eventually resolve the issue as the dependency graph advances, but the resolution could be slow, especially if the sequencer is down or equivocating, or if chains in the dependency graph stop batching. Investigate the causes of such incidents.
 
-### FM3: Valid message is initiated but never relayed in destination although is safe to include
+### FM3: Valid message is initiated but never relayed in destination although it is safe to include
 
 - **Description:** A user (or contract) may send a valid cross-chain message, but the final relay step—`relayMessage` or `validateMessage`—never occurs (or is dropped before to gain a safe status) even when the initiated message is included in a finalized block on the origin chain.
+
+  Some consequences of this issue are:
+
+  - Inability to `relayETH` in `SuperchainETHBridge`
+  - Inability to `relayERC20` in `SuperchainTokenBridge` to mint `SuperchainERC20`
+  - Any other contract awaiting a time-sensitive `relayMessage`.
+
 - **Risk Assessment:** High.
-  - Potential Impact: Critical. Several scenarios could lead to severe consequences, including:
-    - Inability to `relayETH` in `SuperchainWETH`
-    - Inability to `relayERC20` in `SuperchainTokenBridge` to mint `SuperchainERC20`
-    - Any other contract awaiting a time-sensitive `relayMessage`.
-      If the message is not included within the expiration window, both the message and the underlying action could be considered lost.
-  - Likelihood: Medium. Block builders/sequencers are generally controlled by a single entity per chain.
-- **Mitigations:** From a smart contract perspective, little can be done except allowing calls to `validateMessage` within a deposit context to improve censorship resistance. This is currently under discussion [here](https://github.com/ethereum-optimism/specs/issues/520).
+  - Potential Impact: High. If the message failure is not related to a time-sensitive operation but is due to the message being incorrect, it could be considered lost.
+  - Likelihood: Medium. Block builders/sequencers are generally controlled by a single entity per chain. Additionally, if the relay failed on destination due to an incorrect state and after some time it is safe to be relayed again, you can do it even if it expired by call `resendMessage` on origin chain.
+- **Mitigations:**
+  - If the problem is that the message is expired, calling `resendMessage` on origin chain to make it available again to be relayed.
+  - From a smart contract perspective, allowing calls to `validateMessage` within a deposit context to improve censorship resistance. This is currently under discussion [here](https://github.com/ethereum-optimism/specs/issues/520).
 - **Detection:** Monitoring tools should track whether every initiated message has been validated at the destination by checking identifiers. Support tickets filed by users reporting the issue sustain the severity of the case in some situations.
 - **Recovery Path(s):** Depends on sequencer/chain governor policy operations.