restore: persist descriptor refs in job_info, not RestoreDetails

[kev-cao]

At ~1M descriptors, persisting full marshaled descriptor protos into
RestoreDetails.{Table,Type,Schema,Database,Function}Descs (and from
there into the system.job_info payload row) pushes the row past the
64 MiB raft command size limit, so execution can't even start
ingesting. #170974 already removed planning-side population of these
fields; this PR removes execution-side population too.

Each restored descriptor's (ID, Version) tuple is persisted to a
dedicated system.job_info row keyed by descriptor type
(restore_table_desc_refs, restore_type_desc_refs, ...). Per-row
size is bounded by kv.raft.command.max_size independently of the
payload, so at 1M descs each row is on the order of ~16 MiB — well
under the limit. Descriptor bodies are read from KV at Resume time
via the batched descsCol.MutableByID().Descs(ctx, ids) pattern that
prefetchDescriptors already uses.

A new cluster version V26_3_DescriptorIDsInRestoreDetails gates the
behavior change. Below the gate the new info-key rows are written
and the legacy slices are populated, so a restore job created on a
new binary can still be driven by a node on the old binary during a
mixed-version window. Once the gate is active only the info-key rows
are written. Readers always prefer the info-key rows and fall back to
the legacy slices, which covers jobs created before any new code ran.

The early commits scaffold protos, helpers, and the gate; the middle
commits hoist a single descriptor fetch in doResume and migrate
each reader (the rekey list, stats notification, dropDescriptors,
setDescriptorsOffline, etc.); the last three commits flip the gate
on and fix two paths the gate broke (the revlog pipeline, which read
descriptors from the now-nil slice, and the download job's
OnFailOrCancel, which looked up info-key rows under the wrong job
ID).

Informs: #170974

Epic: none

Release note: None

[trunk-io]

Merging to master in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[blathers-crl]

Your pull request contains more than 1000 changes. It is strongly encouraged to split big PRs into smaller chunks.

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}

[cockroach-teamcity]

This change is 

[kev-cao]

Claude (Opus 4.7):

Splitting this in two for easier review. This PR stays open as the
umbrella / end-to-end view; the two child PRs are what actually land:

• restore: scaffold + dual-write descriptor refs to job_info #171340 — write side: scaffold (proto, info-key constants, CV, helpers)
  and dual-write (ID, Version) tuples to dedicated system.job_info
  rows. Purely additive — no reader consumes them yet, no user-visible
  behavior change.
• restore: migrate readers + gate legacy descriptor writes #171341 — read side + gate flip: hoist a single prefetchDescriptors
  call in doResume, migrate every reader off
  RestoreDetails.{Type}Descs, gate the legacy writes on
  V26_3_DescriptorIDsInRestoreDetails, copy descriptor refs into the
  download job, and add TestRestoreDescriptorRefs. Stacked on restore: scaffold + dual-write descriptor refs to job_info #171340
  — its diff currently includes the bottom two commits from restore: scaffold + dual-write descriptor refs to job_info #171340 and
  will shrink once that lands.

This umbrella PR will not be merged. After both children merge I'll
close it.