[txn] Back off when TiKV ignores committed_locks and repeats a lock conflict

## Enhancement

TiDB may put a transaction's start TS in a request's `Context.committed_locks` after resolving its lock as committed. This is a hint, not a guarantee that every TiKV version or read path honors it. If TiKV ignores the hint and returns `KeyIsLocked` for the same transaction, TiDB can repeatedly resolve the already-committed lock and retry the same read without sleeping. This produces unproductive RPCs and extra read I/O until the residual lock is cleaned up or the retry budget is exhausted.

The coprocessor path illustrates the risk: `copIteratorWorker.handleLockErr` calls `ResolveLocksWithOpts`, but only backs off when the returned TTL is positive. A committed lock has TTL 0, so a repeated conflict after `committed_locks` was sent can immediately retry. Please audit the equivalent point-read and KV scan paths in client-go as part of the fix.

### Expected behavior

- If a response reports a lock whose start TS was **already included in that request's** `committed_locks`, treat it as a failed read-through hint and apply a bounded transaction-lock backoff before retrying. Do not spin just because lock resolution returns TTL 0.
- Keep the first retry after newly discovering that a lock committed fast; only back off when TiKV has demonstrably ignored a hint already sent for that lock.
- Respect the existing retry budget, deadline, and cancellation. Preserve the existing correctness/visibility behavior; this is a performance safeguard, not a request to ignore the conflict.
- Add tests with a mocked TiKV response that keeps returning the same lock despite the hint. Verify the backoff is invoked and repeated attempts are bounded, while a server that honors the hint is not slowed down.

### Context

TiKV NextGen support for `committed_locks` is tracked by tidbcloud/cloud-storage-engine#6343 and partially implemented in tidbcloud/cloud-storage-engine#6344. That PR covers Get / BatchGet, local coprocessor, and KV Scan, but paths such as remote coptask still ignore the hint and can return the same lock conflict. Therefore TiDB needs this client-side safeguard even after that TiKV PR lands; it is also useful during rolling upgrades with older TiKV versions. Repeated rapid retries are also a possible contributor to the read-I/O amplification investigated in tidbcloud/cloud-storage-engine#5774; that connection should be measured rather than assumed proven.

Start with copIteratorWorker.handleLockErr and its ResolveLocksWithOpts call, then trace the equivalent point-read and KV scan paths in client-go, including remote coptask if applicable. Inspect how committed_locks and retry budgets are handled. Done means mocked repeated lock responses trigger bounded backoff after a failed hint, while honored hints remain fast and cancellation and deadlines are preserved.

Written by the indexing model from the issue text.