kvserver: leader lease scalability

**Describe the problem**

From @miraradeva, @iskettaneh,

This issue tracks leader lease scalability improvements identified from some escalations:
- start replicas off asleep (need to check if this even makes sense, e.g. they might just wake up immediately)
- improve de-fortification (either add backoff or augment the protocol with an ack mechanism)
- for the overloaded case, I think we have metrics/logs, but maybe we need a runbook to confirm this is the issue.
- read more on https://cockroachlabs.slack.com/archives/C0KB9Q03D/p1786378254685069

Adding a couple more:
- allow leaders to sleep (similarly to epoch lease quiescence); we should first validate if the complexity of the new handshake between leader and followers is worth it
- not necessarily related to scalability but we can work on a lease transfer protocol that doesn't require expiration leases; we've had a few examples of that temporary state being vulnerable

Jira issue: CRDB-66925

Start by locating the kvserver leader-lease implementation and reviewing the listed escalation cases, then read the linked Slack discussion and Jira issue CRDB-66925. The issue contains several possible protocol and operational improvements but does not select one or define a single completion condition, so scope and done criteria need to be established first.

Written by the indexing model from the issue text.