sql,kv: span configuration-required splits substantially increase range counts in some environments

**Describe the problem**

A recent analysis of a cockroach cloud host cluster found a surprising number of small ranges, including a large number of ranges < 1MB.

```
------------------------------------------------------------------------
HISTOGRAM
------------------------------------------------------------------------
empty (0 B) 59469 41.7% ################################################
(0, 1 MiB] 56543 39.6% #############################################
(1, 8 MiB] 18512 13.0% ##############
(8, 32 MiB] 2214 1.6% #
(32, 64 MiB] 527 0.4%
(64, 128 MiB] 857 0.6%
(128, 256 MiB] 2123 1.5% #
(256, 512 MiB] 2502 1.8% ##
> 512 MiB 0 0.0%
```

Further analysis showed that the vast majority of these splits are actually _required_ because of zone configuration differences between system tables, specifically the ExcludeFromBackup option. As a result, every tenant produces at least 10 ranges, regardless of data size.

What is particularly interesting is that further analysis of the zone configuration in this cluster found only 51 _unique_ span configurations across the 100s of thousands of span configurations in the cluster.

While the above analysis is particular to multi-tenancy, the same basic problem can also occur in signle-tenant clusters that make use of multi-region primitives, the exclude from backup option, custom gc.ttlsecond values, etc.

While inactive ranges are cheap compared to active ranges, they still consume resources and contribute to the cost of various O(ranges) operations.

Jira issue: CRDB-66995

Epic CRDB-62481

The issue names no files, tests, or entry points. Start by tracing how zone-configuration differences, especially ExcludeFromBackup, cause configuration-required splits and measure the resulting range counts; done means reducing redundant splits while preserving required configuration boundaries across multi-tenant and multi-region cases.

Written by the indexing model from the issue text.