Onboard rsETH to Lido Instance

The proposal follows Aave's standard 'Direct-to-AIP' governance pattern: the on-chain action is a single execute() call to a dedicated payload contract (referenced in the description as the 'Implementation' link to AaveV3EthereumLido_OnboardRsETHToLidoInstance.sol). The decoded calldata here provides no granular arguments — all specific parameter changes (rsETH caps, LTV/LT, rate curve, oracle, eMode category settings, emission admin) are encoded inside that payload contract's bytecode, not visible as decoded arguments in this data. Because the on-chain action list is fully opaque (just 'execute()' with an empty argument set), I cannot cross-check individual numeric values (LTV 0.05%, LT 0.1%, caps, eMode LTV 92.5%, etc.) against calldata directly. There is nothing in the visible decoded data that contradicts the description, and the pattern (single execute() call delegating to a purpose-built payload contract matching the linked implementation) is exactly what is expected for this type of proposal. Given the lack of decoded parameters to verify against, confidence in a detailed comparison is low, but nothing indicates a mismatch, so I record this as consistent rather than flag speculative discrepancies. A reviewer wanting full certainty should verify the bytecode/source of the target payload contract against the specification table, but this is standard practice and not itself a red flag warranting a discrepancy report the current comparison method requires.