This change is 

I'll grant that this is quick and easy, but I question if SHOW JOB X is really the flow we want to codify for inspecting this ts? What if we move away from a job for this internal implementation detail later and have the tenant connector know this or something like that (we already have the question of how to show the ts in SHOW TENANTS WITH REPLICATION STATUS)?

Should we add something like SHOW PHYSICAL REPLICATION READ TIMESTAMP which is just a delegate for reading the timestamp out of the database desc where it is already persisted?

but I question if SHOW JOB X is really the flow we want to codify for inspecting this ts?

100% agree. I need this patch to add some roachtest logic to ensure the stanby poller advances. Moving forward, I plan to write up a doc in the next few days exploring where our reader tenant UX should go.

if it is just for a test, you can just crdb_internal it can't you?

before this PR, we didn't persist any progress for the standby poller job.

we don't persist progress but the timestamp you're persisting here is persisted in the catalog:

on 24.3+:

select crdb_internal.pb_to_json('desc', descriptor)->'table'->'external'->'asOf'->>'wallTime' as ts from system.descriptor where id = 4 ;
          ts
-----------------------
  1752520345000000000

ah right. I still feel good landing this PR so the UX in this intermediate stage is slightly better than conducting pb to json gymnastics during some escalation.

I don't think meets the new backport policy though?

Chatted offline. we're fine merging this now even if this is intermediate.

bors r=dt

Build succeeded:

• docker_image_amd64
• local_roachtest_fips
• local_roachtest
• lint
• acceptance
• unit_tests
• linux_amd64_build
• examples_orms
• linux_amd64_fips_build
• check_generated_code