pts: Table-scoped PTS records not very useful without table schema

```
root@127.0.0.1:26257/movr> alter range default configure zone using gc.ttlseconds = 1; alter database system configure zone using gc.ttlseconds = 1;
CONFIGURE ZONE 1
CONFIGURE ZONE 1

# just verify that rides == 108 for later.
root@127.0.0.1:26257/movr> select id from system.namespace where name = 'rides';
108

# drop a poor-man's PTS on movr.rides with a backup that pauses itself instantly.
root@127.0.0.1:26257/movr> set cluster setting jobs.debug.pausepoints = 'backup.before.write_first_checkpoint';
root@127.0.0.1:26257/movr> backup table movr.rides to 'nodelocal://1/pts';

# Verify our PTS: we see 108, the ID we checked earlier, is protected. Note the timestamp that is protected for later.
root@127.0.0.1:26257/movr> select ts, decoded_target from crdb_internal.kv_protected_ts_records;
1710284886235203000.0000000000 | {"ignoreIfExcludedFromBackup": true, "schemaObjects": {"ids": [108]}}

# Cause the leased desc to be invalid.
root@127.0.0.1:26257/movr> create user dt; grant select on movr.rides to dt;

# Time passes. Make it pass faster for this test.
root@127.0.0.1:26257/movr> select crdb_internal.kv_enqueue_replica(7, 'mvccGC', true);

# Okay, so we protected `rides` and can go read it as of the protected time now... right?
root@127.0.0.1:26257/movr> select count(*) from movr.rides as of system time 1710284886235203000.0000000000;
ERROR: error in retrieving descs between 1710284886.235203000,0, 1710284906.192126000,0: batch timestamp 1710284886.235203000,0 must be after replica GC threshold 1710284913.609103000,0

# "in retrieving descs" you say? Let's try that directly...
root@127.0.0.1:26257/movr> select id from system.descriptor as of system time 1710284886235203000.0000000000 where id = 108;
ERROR: batch timestamp 1710284886.235203000,0 must be after replica GC threshold 1710284913.609103000,0
```

Jira issue: CRDB-36662

Epic CRDB-61003