This prevents the hazard described in
https://github.com/cockroachdb/cockroach/blob/5f63ac527becd4aae5cfbdaa76b7de28e07b8767/pkg/storage/concurrency/concurrency_control.go#L480.

I've been trying to (starting with cockroachdb#45085) clean up `spanset.Batch`
to the point where it would have been able to detect this unlatched
key access, but getting that all the way over the fence is a little
tricky due to:
- `GCRequest` span declaration - should this even latch?
- transactional `Put` span declaration - does this need to declare a
  write span all the way back to txn.MinTimestamp because it might move
  an existing intent forward?
- `spanset.Iterator` semantics and its interaction with `pebbleMVCCScanner` -
  what can the `spanset.Iterator` even assert here, given that the scanner
  itself is determining whether to ignore values or not.

Unfortunately, without a rework, the current attempt at asserting
correct timestamp access in `spanset.Batch` is hopelessly broken.
Not only does the verification not encode the correct rules for
declared timestamps (e.g. a write at time 10 should permit writing at
any time >= 10), but the timestamp it works with isn't even the correct
timestamp. It compares the declared span timestamps against the batch
header timestamp, which completely misses the point. It should be
comparing the declared span timestamps against the timestamps of actual
uses of the `spanset.Batch` so that we're actually asserting that the
batch is being used correctly.

I'd like to fix all of this, but not here.