fix(lockservice): bound remote wait-for snapshot retries

[aptend]

What type of PR is this?

• API-change
• BUG
• Improvement
• Documentation
• Feature
• Test and CI
• Code Refactoring

Which issue(s) this PR fixes:

Fixes #25870

What this PR does / why we need it:

#25901 made remote wait-for snapshot retries context-aware, so caller cancellation and detector shutdown now propagate correctly. However, deadlock-detector checks run with a service-lifetime context. While the service remains live, a permanently unavailable remote lock-table owner can still keep remoteLockTable.getLock retrying forever and occupy one of the four detector workers indefinitely.

This PR adds a 35-second deadline to one remote lock-key snapshot lookup. The bound covers a failed GetTxnLock RPC, bind refresh, retry backoff, and another RPC attempt. It deliberately does not bound an entire transaction snapshot or wait-for graph traversal: healthy checks may need to scan many lock keys and transactions, and a cumulative deadline would repeatedly restart the traversal and could permanently miss a deeper deadlock edge.

On timeout, the existing error path unwinds the deadlock check, removes the transaction from activeCheckTxn, and returns the worker to the detector queue. Caller deadlines and detector shutdown cancellation still take precedence over the internal bound.

The regression test fills all four detector workers with blocked remote snapshot lookups, verifies that they return with context.DeadlineExceeded, confirms activeCheckTxn cleanup, and proves that a fifth queued check is processed without invoking the deadlock-abort callback.

Validation:

• focused lockservice tests with -count=50
• focused race tests with -count=10
• full pkg/lockservice test suite
• full pkg/lockservice race suite
• go build ./pkg/lockservice
• go vet ./pkg/lockservice
• dependent pkg/util/status tests

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[gouhongshen]

Codex automated review

No findings. The timeout cleanly bounds the previously infinite remote snapshot retry chain, preserves earlier cancellation, releases detector workers and active-check state, and allows periodic rechecks. Focused tests passed 20 runs and 10 race-enabled runs; CI is green.

[XuPeng-SH]

Reviewed exact head 097dba6. No blocking findings. The per-lock-key deadline preserves earlier caller/shutdown cancellation, bounds the GetTxnLock + bind-refresh + backoff retry chain, releases detector workers and activeCheckTxn state on timeout, and leaves periodic rechecks intact without imposing a cumulative traversal deadline. Independently passed focused tests (20 runs), focused race tests (10 runs), full pkg/lockservice tests with and without -race, pkg/util/status tests, go vet, and go build.

[mergify]

Merge Queue Status

• ✅ Entered queue — 2026-07-22 10:24 UTC · Rule: main · triggered by rule Automatic queue on approval for main
• 🟠 Checks running · in-place
• 🚫 Left the queue — 2026-07-22 11:05 UTC · at 3cbeabdfb1d0253b16dbfae37042494780600b47

This pull request spent 40 minutes 10 seconds in the queue, with no time running CI.

Reason

The pull request can't be updated

head ref does not exist

Hint

You should update or rebase your pull request manually. If you do, this pull request will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue, you can requeue the pull request, without updating it, by posting a @mergifyio queue comment.

Tick the box to put this pull request back in the merge queue (same as @mergifyio queue).

• Requeue this pull request