fix: capture context slot consistently in getSignatureStatuses RPC

[serejke]

The getSignatureStatuses RPC endpoint had a race condition that caused inconsistent API responses when querying transaction statuses. The context slot was captured after each signature lookup in a loop, rather than once at the beginning of the method call.

Problem Discovery

This bug was discovered during high-throughput transaction processing when:

• Sending many transactions at once to the network
• Calling getSignatureStatuses from a background confirmation process
• Observing that some responses returned null with a high context slot
• But post-factum finding the transaction was included in an earlier slot

This created an inconsistency where the API would report "transaction not found" with context slot X, but the transaction actually existed in slot Y where Y < X. This violates the semantic contract that if a transaction is not found at slot X, it should not exist in any slot <= X.

Root Cause

The bug was in the implementation of get_signature_statuses(). The method captured the context slot inside the signature lookup loop:

let mut last_latest_absolute_slot = 0;
for signature in signatures.into_iter() {
    let res = svm_locker.get_transaction(...).await?;
    last_latest_absolute_slot = svm_locker.get_latest_absolute_slot();
    responses.push(res.map_some_transaction_status());
}

The RwLock on SurfnetSvm is held only during individual operations, not across the entire RPC call. During the .await points in the async loop, other tasks can acquire the write lock and advance the slot (e.g., by confirming blocks or processing new transactions).

This created a race condition where:

1. Lookup transaction at slot 100 → not found (perhaps due to timing)
2. Async await point allows other tasks to run
3. Another task acquires write lock and advances slot to 101
4. get_latest_absolute_slot() returns 101
5. Response reports "not found" with context slot 101
6. But the transaction actually exists in slot 100

Solution

Capture the context slot once at the beginning of the method, before any signature lookups. This ensures all responses in a batch share the same snapshot view of the blockchain state, even if the slot advances during processing:

let context_slot = svm_locker.get_latest_absolute_slot();
for signature in signatures.into_iter() {
    let res = svm_locker.get_transaction(...).await?;
    responses.push(res.map_some_transaction_status());
}

This provides snapshot consistency: all lookups are evaluated as of the same slot, preventing temporal inconsistencies in batch responses.

Impact

This fix ensures getSignatureStatuses provides consistent, predictable responses during high-throughput transaction processing and parallel confirmation workflows.

[MicaiahReid]

Thank you for the thoughtful explanation and for the fix, @serejke!