kvserver: queues enqueue follower replicas under leader leases, wasting merge queue throughput

**Describe the problem**

Under leader leases, every `needsLease` queue enqueues follower replicas, which are then popped and dropped without a trace.

The add-time filter in `baseQueue.maybeAdd` → `replicaCanBeProcessed` ([pkg/kv/kvserver/queue.go](https://github.com/cockroachdb/cockroach/blob/master/pkg/kv/kvserver/queue.go)) only rejects a replica when it can positively see a valid lease owned by another store: `if st.IsValid() && !st.OwnedBy(repl.StoreID())`. But a follower of a healthy leader-lease range can never prove the remote lease valid: once the lease's `MinExpiration` has passed, validity is defined by raft leader support, which only the leader can evaluate, so `leases.Status` ([pkg/kv/kvserver/leases/status.go](https://github.com/cockroachdb/cockroach/blob/master/pkg/kv/kvserver/leases/status.go), the `LeaseLeader` not-owned-locally branch) returns `LeaseState_ERROR` ("leader lease is not held locally, cannot determine validity") — and `IsValid()` is false, so the filter passes. Under epoch and expiration leases the follower could verify validity (via the liveness record or the timestamp), so this filter used to wor. Every enqueued follower entry is then popped and discarded at the pop-time lease check (`processReplica` → `redirectOnOrAcquireLease` → `NotLeaseHolderError` → `errMarkNotAcquirableLease` → `return nil`), incrementing no metric (not successes, failures, or purgatory) and logging only at V(3).

Jira issue: CRDB-67818

Start in pkg/kv/kvserver/queue.go at baseQueue.maybeAdd and replicaCanBeProcessed, then trace lease behavior in pkg/kv/kvserver/leases/status.go. Follow processReplica through redirectOnOrAcquireLease and the NotLeaseHolderError path. Done means follower replicas under leader leases are filtered appropriately instead of being enqueued and discarded without accounting.

Written by the indexing model from the issue text.