Fix Critical Race Condition in ORDERED_ALLOW_TIMEOUT Channel Processing

[leopardracer]

Problem

The ORDERED_ALLOW_TIMEOUT channel type had a critical race condition vulnerability where the nextSequenceRecv counter could be incremented twice:

1. First increment during timeout processing (lines 897-905)
2. Second increment during normal processing (lines 925-927)

This violated the "exactly-once delivery" guarantee and could cause subsequent packets to be rejected.

Fix

• Separated ORDERED and ORDERED_ALLOW_TIMEOUT cases in the sequence increment logic
• Ensured immediate return after timeout processing to prevent double increment
• Maintained correct packet ordering semantics

Security Impact

• Critical: Fixed race condition that could break channel functionality
• Prevents: Packet loss and channel state corruption
• Maintains: Protocol safety guarantees