concurrency: committed transaction's unresolved intents can cause spurious lock timeout errors

## Summary

A transaction with a short `lock_timeout` can hit a `55P03` (lock not available) error when it encounters an intent belonging to a transaction that has already committed. This happens because CockroachDB's parallel commit protocol allows a transaction to return success to the client while its intents are still being resolved asynchronously. If another transaction encounters those intents before resolution completes and has a tight lock timeout, it will block on the intent, fail to push the STAGING transaction record within the timeout, and return a spurious lock timeout error.

## Details

The sequence is roughly:

1. **Txn A** commits via parallel commit — its transaction record moves to STAGING and the client sees success. Async intent resolution begins in the background.
2. **Txn B** starts shortly after and performs a locking read (or write) that encounters one of Txn A's unresolved intents.
3. Txn B enters the lock wait queue for the intent.
4. Txn B's `lock_timeout` expires before async intent resolution completes.
5. The fallback push finds Txn A still in STAGING (not yet finalized to COMMITTED), so the push doesn't resolve the intent.
6. Txn B receives a lock timeout error, even though Txn A has already committed and the lock would have been released momentarily.

This is a pre-existing behavior, not a correctness issue — the client can retry and succeed. But it creates flaky test failures (e.g., #164738) and could cause unnecessary retry overhead in production workloads that use short lock timeouts.

## Observed In

The `lock_timeout` logic test under `local-repeatable-read` config, where metamorphic knobs (column family mutation + small delete-range chunk size) cause a simple single-row DELETE to use pipelined writes and parallel commit. The subsequent statement hits the unresolved intent within its 1ms lock timeout window.

Jira issue: CRDB-61207