ptstorage: lock the meta row during protect and release

[stevendanna]

Both protect and release read the singleton system.protected_ts_meta
row via currentMetaCTE, then upsert a new version of it. Concurrent
callers all read the row at the same HLC, all try to write a new
version, and the losers retry on WriteTooOld. Beyond ~100 retries the
call errors out. Successful retries still leave MVCC versions piled up
on the meta row, so subsequent reads scan more history and slow down
over the life of the cluster.

This PR acquires an exclusive lock on the meta row during the CTE
read. Concurrent callers queue at the lock instead of colliding on the
upsert. FOR UPDATE is bound to the real-table leg of the CTE so the
synthetic zero-row fallback (used when no meta row exists yet) does
not lock anything. getMetadataQuery is read-only and keeps using the
non-locking CTE.

BenchmarkProtect and BenchmarkRelease, added alongside, measure
throughput at 128 concurrent writers on an in-process server:

name                    old sec/op     new sec/op     delta
Protect/workers=128-10  44.744m ± 25%   9.911m ± 42%  -77.85% (p=0.000 n=10)
Release/workers=128-10  55.683m ± 41%   9.768m ± 52%  -82.46% (p=0.000 n=10)

The baseline runs also produced retry-budget-exhaustion errors during
ramp-up (errs/op 0.13–0.32 in the first trial); after the change
errs/op is 0 across all trials.

Epic: none

Release note (performance improvement): Concurrent protected timestamp
protect and release calls (used heavily by backup and changefeed) now
serialize on the meta row rather than racing into WriteTooOld retries.
Workloads that create or release many protected timestamp records at
once see substantially higher throughput.

[trunk-io]

😎 Merged successfully - details.

[cockroach-teamcity]

This change is 

[stevendanna]

I'm going to follow up by ripping this write out hopefully, but the FOR UPDATE does seem to help in high concurrency situations.

[stevendanna]

/trunk merge

TFTR!