DS-1850 - Fix Overlap in calculated streams

[dav009]

https://smartcontract-it.atlassian.net/browse/DS-1850

Details

https://smartcontract-it.atlassian.net/wiki/spaces/DAST/pages/2159149092/DS-1751+-+Investigation+on+timestamp+range+violations

Why ?

• Currently for calculated streams we output reports where ValidFromTimestamp > ObservationTimestmap . This violates the timestamp invariant

What ?

• Calculated streams (evm_abi_encode_unpacked_expr ) are included in seconds-resolution pre-validation filtering in the IsSecondsResolution().

Details

Current behaviour

//sample llo outcome telemetry for a channel/stream
observationTimestampNanoseconds: 1765173183742021148,
validFromNanoseconds: 1765173183016097280
// unpacked_expr encoder would create the following  report
validFromSeconds := uint64(1765173183016097280) / 1e9 => 1765173183  
observationTimestampSeconds uint64(1765173183742021148) / 1e9 => 1765173183
report.validFromSeconds = 1765173183 + 1 
report.observationTimestampSeconds = 1765173183
^ causes invariant violation

expected behaviour (introduced by changes in this PR)

// information flow chainlink-data-streams/llo/plugin_outcome.go
  Round N (Overlap detected):
  ObservationTimestamp: 1765173183.742 sec → 1765173183 sec
  ValidAfter:           1765173183.282 sec → 1765173183 sec
                        ^^^ SAME SECOND ^^^
  IsReportable() → FALSE (unreportable due to overlap)
  No report generated ✗
  ValidAfterNanoseconds stays: 1765173183282997914 (unchanged!)
  Round N+1 (Next observation, ~milliseconds later):
  ObservationTimestamp: 1765173184.123 sec → 1765173184 sec  ← New observation
  ValidAfter:           1765173183.282 sec → 1765173183 sec  ← Same as before!
                        ^^^ DIFFERENT SECONDS ^^^
  IsReportable() → TRUE ✓
  Report generated with:
    ValidFromTimestamp: 1765173183 + 1 = 1765173184
    Timestamp:          1765173184
  ValidAfterNanoseconds updated to: 1765173184123000000 (current observation)
  Key Points:
  1. ValidAfter doesn't advance when a report is skipped
    - This ensures no gaps in coverage
  2. ValidAfter only advances when a report is successfully generated
    - It gets set to the observation timestamp of the successful report
  3. The "skipped" timestamp range still gets covered
    - The next report with a later observation timestamp will have:
        - ValidFrom = old_validAfter + 1
      - Timestamp = new_observation
    - This means the report is valid from when the previous report expired