kvserver/concurrency: VIR push path assumes the conflicting lock is replicated

**Describe the problem**

This is a latent hazard with a minor live inefficiency, not a correctness bug today.

A non-locking reader can be blocked by an *unreplicated-only* exclusive lock. After a successful push, the waiter's VIR path unconditionally calls `AddReplicatedToResolveAndSignal` ([lock_table_waiter.go#L626](https://github.com/cockroachdb/cockroach/blob/a7e117882b4356096b3a8ea26046baa7e5d53fce/pkg/kv/kvserver/concurrency/lock_table_waiter.go#L626)), stuffing the update into `toResolve` — violating the documented invariant that "toResolve should only include replicated locks" ([lock_table.go#L532](https://github.com/cockroachdb/cockroach/blob/a7e117882b4356096b3a8ea26046baa7e5d53fce/pkg/kv/kvserver/concurrency/lock_table.go#L532)).

It self-corrects: the subsequent rescan routes the lock through `toResolveUnreplicated`/`updateLockInternal`. But the stale point entry persists in `toResolve` for the guard's lifetime and produces a no-op `ResolveIntent` against the temp batch on every evaluation. More importantly, code downstream of `toResolve` is entitled to assume the documented invariant, and this path quietly breaks it.

**Suggested fix**

Have the waiter check whether the conflict is held replicated before choosing the VIR path, so unreplicated-only conflicts never enter `toResolve`.

**Additional context**

Found during an agent-assisted correctness audit of `pkg/kv/kvserver/concurrency`. Code links are pinned to master @ a7e1178.

Jira issue: CRDB-65664

Start in pkg/kv/kvserver/concurrency/lock_table_waiter.go around line 626 and compare the VIR path with the invariant documented in lock_table.go around line 532. Trace how unreplicated-only conflicts are handled during the subsequent rescan. Done means such conflicts never enter toResolve and the documented replicated-lock invariant remains intact.

Written by the indexing model from the issue text.