Document that Row-level TTL does job checkpointing

src/current/v25.4/row-level-ttl.md

@@ -26,6 +26,7 @@ At a high level, Row-Level TTL works by:
 - Issuing batched [`DELETE`]({% link {{ page.version.version }}/delete.md %}) statements for the expired rows.
 - As part of the above process, deciding how many rows to [`SELECT`]({% link {{ page.version.version }}/select-clause.md %}) and [`DELETE`]({% link {{ page.version.version }}/delete.md %}) at once in each of the above queries.
 - Running the SQL queries described above in parallel as [background jobs]({% link {{ page.version.version }}/show-jobs.md %}).
+- Periodically checkpointing progress across key spans so that if a TTL job is retried, paused and resumed, or a node restarts, it resumes from the last checkpoint without reprocessing spans that were already completed.
 - To minimize the performance impact on foreground application queries, the background deletion queries are rate limited; they are also submitted at a lower priority level using the [admission control system]({% link {{ page.version.version }}/admission-control.md %}). When foreground traffic increases, CockroachDB will reduce the resources allocated to TTL deletes to handle the foreground traffic. When foreground traffic decreases, CockroachDB will increase the resources allocated to TTL deletes.
 
 - Latency of row-level TTL queries is further reduced by using the elastic CPU limiter, which dynamically controls the total CPU percentage used by row-level TTL reads. The elastic CPU limiter can be disabled for row-level TTL queries by setting the `kvadmission.low_pri_read_elastic_control.enabled` and `sqladmission.low_pri_read_response_elastic_control.enabled` [cluster settings]({% link {{ page.version.version }}/cluster-settings.md %}) to `false`.