Inaccurate debug message in `verifyCanAddTimestamp()` when `seal.Timestamp == ts`

[lucasmt]

verifyCanAddTimestamp() in logsdb.go returns early if the timestamp of the last sealed block in the LogsDB is greater than the timestamp of the block we're currently trying to insert:

_audits_Ethereum-optimism_optimism_interopv2/op-supernode/supernode/activity/interop/logdb.go

Lines 169 to 178 in bd29b7d

	// determine the timestamp of the last sealed block
	seal, err := db.FindSealedBlock(latestBlock.Number)
	if err != nil {
	return eth.BlockID{}, hasBlocks, fmt.Errorf("chain %s: failed to find sealed block %d: %w", chainID, latestBlock.Number, err)
	}
	// if the last sealed block is already after the timestamp in question, return success
	if seal.Timestamp > ts {
	return latestBlock, hasBlocks, nil
	}

Consider changing seal.Timestamp > ts to seal.Timestamp >= ts. The case when the two are equal might happen if we are trying to re-execute a pending transition that failed after the block was inserted. In this case, gap := ts - seal.Timestamp will be calculated as 0, which will produce the following debug message:

_audits_Ethereum-optimism_optimism_interopv2/op-supernode/supernode/activity/interop/logdb.go

Lines 188 to 198 in bd29b7d

	// If the gap is less than a block time, we can still append the timestamp to the database.
	// This is expected for chains whose block time is greater than one second, since the
	// interop timestamp may legitimately fall between consecutive L2 blocks.
	if gap < blockTime {
	i.log.Debug("verifyCanAddTimestamp: timestamp falls between L2 blocks for this chain; this can be expected for chains with block times greater than one second",
	"chain", chainID,
	"timestamp", ts,
	"block time", blockTime,
	"gap", gap,
	)
	}

Although this doesn't change the result of the timestamp verification, the debug message is not appropriate for this case, since the gap being 0 is independent of the block time and simply a product of trying to re-insert the same block. Returning early in the seal.Timestamp == ts prevents this.