sql/ttl: move from per-tick job records to one-long-running-job-per-table model

**Is your feature request related to a problem? Please describe.**

Per-table TTL currently creates a new job record on every cadence tick. At scale this is a top job-system load contributor: per @dt's investigation, TTL job creation is second only to auto-stats jobs (and becomes the leading job-creator once stats jobs are fixed in the broader many-tables work). At default daily cadence × 100K TTL-enabled tables that's 100K new records every 24h; at hourly cadence that's 2.4M/day. Discussed in #proj-1m-tables on 2026-05-20: [thread link](https://cockroachlabs.enterprise.slack.com/archives/C0APP6FTMPF/p1779305167683399).

**Describe the solution you'd like**

Move per-table TTL to a one-long-running-job-per-table model. The job persists for the lifetime of the table, sleeps between cycles based on the table's TTL schedule, and is pinged (via signal/intent) to wake for execution. Externally: one entry per table in `SHOW JOBS` instead of N entries per tick.

This aligns TTL with the broader "long-lived jobs that sleep" pattern Jobs is moving toward (see #170674 for the jobs registry rangefeed work that supports this).

Aligns with broader many-tables scaling work. Originally filed under the 100K-tables epic (CRDB-62272); moved to the 1M-descriptor epic (CRDB-58778) when the 100K epic closed, to be evaluated at 1M scale.

**Describe alternatives you've considered**

- *Keep status quo, optimize the per-tick path.* Doesn't address the structural `O(tables × ticks)` job-record creation.
- *More aggressive consolidation (one job per cluster or per database for all TTL).* Considered in the 05-20 thread and rejected — would require restructuring how TTL coordinates per-table state, too tall an ask for now.

**Additional context**

Known trade-offs (per 05-20 thread consensus):
- One goroutine per TTL-enabled table. At 1M TTL tables, ~2GB+ of goroutine stacks across the cluster. Accepted: "configuring a million ttls is a choice; allocate the resources for that" — @dt.
- Observability changes: multiple runs tied to one job entry rather than separate jobs. Can be mitigated with per-run labels.

Ownership note: TTL recently moved to SQL Queries; @MattSpilchen (prior owner, SQL Foundations) for context, @mw5h (current owner).

Coordinates with #170674.

Epic CRDB-58778
Jira issue: CRDB-64579