Update legacy guardian

The proposal description is highly detailed, specifying exact functions (setEmergencyAdmin, addEmergencyAdmin, removeEmergencyAdmin) and exact new/old guardian addresses per network for both Protocol and Governance Guardian roles. However, the decoded on-chain actions only show three top-level 'execute()' (fallback) calls to payload contracts on Ethereum mainnet. This is the standard Aave governance pattern where the mainnet proposal invokes payload contracts whose internal logic (including any cross-chain messaging via bridges to Polygon, Avalanche, Optimism, Arbitrum, Base, Gnosis, Scroll, Metis, BNB) is not exposed in the decoded top-level calldata — only the entry-point call is visible, not the internal state changes it performs. Because the decoding tool did not surface the internal instructions of these payload contracts (addresses, function calls, arguments), it is not possible to directly verify whether the specific claims in the description (correct guardian addresses, correct networks, add/remove emergency admin calls) match the actual execution. The three execute() calls are consistent with the proposal's reference links to multiple implementation contracts (AaveV2Ethereum, AaveV3Ethereum, AaveV3Polygon, etc.), suggesting they are grouped payloads for this guardian update, and nothing in the visible calldata contradicts the description. Given the opacity of the calldata (no decoded arguments beyond generic fallback), confidence in a detailed line-by-line verification is low, but there is no evidence of any mismatch, so the overall assessment remains consistent with low confidence rather than flagging speculative discrepancies.