[F54] [LOW] Stale-price boundary not exercised at uint256 overflow of priceTimestamp + timeout #105

The staleness check computes priceTimestamp + timeout in checked arithmetic. If an FTSO reports a near-uint256-max priceTimestamp (registry/FTSO is a trusted external, but a buggy/compromised FTSO could), priceTimestamp + timeout overflows and the call reverts with a generic Panic(0x11) instead of the intended StalePrice or a clean success. The tests bound timeout and priceTimestamp so this addition never overflows (testRunStale bounds timestamp to type(uint256).max - timeout - 1), so the overflow branch is both untested and surfaces as an opaque panic rather than a domain error. For an oracle reading from a trusted-but-external contract this is a minor robustness/clarity gap.

File(s): src/lib/price/LibFtsoCurrentPriceUsd.sol
Lines: 50-52

Proposed fix
Guard the addition explicitly so an overflowing timestamp is treated as stale rather than panicking, and document it:
// priceTimestamp + timeout can overflow for a misbehaving FTSO; treat an
// overflow as not-stale only if the sum genuinely exceeds block.timestamp.
unchecked {
uint256 deadline = priceTimestamp + timeout;
if (deadline < priceTimestamp || block.timestamp > deadline) {
revert StalePrice(priceTimestamp, timeout);
}
}
and add a fuzz test where priceTimestamp is bound to [type(uint256).max - timeout + 1, type(uint256).max] asserting StalePrice rather than a panic.

Filed by the audit skill (dimension 5-correctness). Findings are problems, not fixes — triage decides disposition.

Co-Authored-By: Claude noreply@anthropic.com