fix: validate all Chainlink feed timestamps against expiry in ChainlinkRelayerV1

[mento-val]

Summary

Fixes a security bug (mento-core S-2 from QA audit MEN-5) where only the newest Chainlink aggregator timestamp was checked against the staleness expiry window.

Problem

In ChainlinkRelayerV1.relay(), when multiple aggregators are used:

// Before: only checks the newest timestamp
if (isTimestampExpired(newestChainlinkTs)) {
    revert ExpiredTimestamp();
}

With two aggregators where feed 0 is stale but feed 1 is fresh, the relay succeeds with stale data influencing the aggregated rate. Example:

Feed	Age	Expired?
Feed 0 (oldest)	700s	Yes (expirySeconds=600)
Feed 1 (newest)	400s	No
Spread	300s	Within maxTimestampSpread

Current code: relay succeeds, stale price from Feed 0 contaminates the result.

Fix

// After: checks the oldest timestamp — if oldest is valid, all are valid
if (isTimestampExpired(oldestChainlinkTs)) {
    revert ExpiredTimestamp();
}

If the oldest timestamp is within the expiry window, all feeds are fresh. If the oldest is expired, at least one feed carries stale data and the relay reverts.

Tests

Adds test_revertsWhenOldestFeedIsExpiredButNewestIsNot to ChainlinkRelayerV1Test_relay_double demonstrating the exact vulnerability scenario.

This PR was initially closed due to CI failures in relay_triple and relay_full test suites. The root cause was that the test function was defined for relay_double (2 aggregators) and inherited by relay_triple (3) and relay_full (4). The inherited setUp timestamps caused a timestamp spread > maxTimestampSpread, firing TimestampSpreadTooHigh before ExpiredTimestamp.

CI fixes (commits 4634545, 8d814f0):

• Warped block.timestamp to prevent underflow in the staleness test
• Marked the base test function virtual and overrode it in relay_triple and relay_full to set all aggregator timestamps, keeping spread ≤300 and ensuring ExpiredTimestamp fires correctly

🤖 Generated with Claude Code

[mento-val]

CI fix pushed — test_revertsWhenOldestFeedIsExpiredButNewestIsNot was panicking with arithmetic underflow (0x11) because Foundry starts block.timestamp at 1, and the test subtracts 700 from it. Added vm.warp(block.timestamp + 1000) at the top of the test to advance time enough for the subtraction to succeed. Also added the foundry-chainlink-toolkit/ remapping to remappings.txt (same as PR #713) since this branch needs it for the ChainlinkRelayerV1 tests to compile.

[mento-val]

QA Review — LGTM / Approved (reviewer cannot self-approve)

Fix logic: Correct.

The one-line change from newestChainlinkTs → oldestChainlinkTs in the expiry check closes the security gap cleanly.

Why the logic holds:

• maxTimestampSpread already constrains all feed timestamps within a window.
• If oldestChainlinkTs is within the expiry window, every feed is guaranteed fresh (all others are newer).
• If oldestChainlinkTs is expired, at least one feed carries stale data → relay correctly reverts.
• The TimestampNotNew check (still using newestChainlinkTs) is unaffected and correct.

Test coverage: Appropriate.

• test_revertsWhenOldestFeedIsExpiredButNewestIsNot in relay_double exercises the exact vulnerability (Feed 0: 700s, Feed 1: 400s, spread: 300s ≤ maxSpread, oldest expired → must revert).
• Overrides in relay_triple and relay_full correctly set ALL aggregator timestamps so inherited setUp timestamps don't trigger a spurious TimestampSpreadTooHigh. These are not masking real failures — they're correctly isolating the expiry assertion from the spread assertion.
• vm.warp(block.timestamp + 1000) before subtracting timestamps prevents underflow — correct defensive test practice.

CI: All 4 checks passing (Lint & Test, Slither, Echidna).

Remapping addition: foundry-chainlink-toolkit entry is benign test tooling infrastructure.

No issues found. LGTM — ready to merge.