CAS GC: batch the namespace janitor's deletes under a soft time budget

[filimonov]

The namespace janitor (GC phase 16) deleted a dropped table's dead _log/_snap keys one page per folding round, with one HEAD + DELETE per key. It now deletes a page's dead keys as write-once batches on the GC I/O pool and keeps taking pages while they delete, until a soft 20 s budget.

A smaller implementation of #2468 (19 files, +858/−65 against 40 files, +3296/−729) and a replacement for it.

Changes

• Gc::runNamespaceJanitor repeats NamespaceJanitor::runOnePage while a page deleted something and published its cursor. No page starts after 20 s; the page in progress finishes. A pool without debris still costs one LIST per round.
• After the last page of cas/ns/ the pass continues from its beginning, so a pass that began mid-stream also reaches the debris before its cursor.
• Dead-life canonical _log/_snap keys are write-once: a page deletes them with no HEAD and no token, split evenly across the GC I/O pool, at most cas_gc_bulk_delete_chunk_keys per request. A store without a batch delete gets one request per key from the same jobs. _ckpt and _files keep the exact-token delete.
• A failed batch, or a job the pool refused, leaks its keys and the cursor advances. Lost authority leaves the page unpublished.
• A failed LIST resets the cursor only on the first page of a pass.
• Phase metrics: delete_requests, budget_exhausted. leaked is zero for a page that did not publish its cursor.

Risks / notes

• On S3 a 1000-key page goes as up to cas_gc_io_concurrency requests (16 × 63 keys by default) instead of one, and on a store without a batch delete each job first spends one refused batch call. Capping by the storage's batch-delete limit (objects_chunk_size_to_delete) is a separate PR.
• Keys of a successful batch count as deleted even when absent. With a LIST that lags behind deletes, a pass can keep taking pages until the budget.
• Each page reads and writes gc/maintenance_state: 2 extra requests per 1000 keys compared with one publication per phase.
• No on-S3 format change.

Testing

• Unit: CAS* gate, debug and ASan. New suite CASNamespaceJanitorBatches (12 tests) and CASWriteOnceKey.StreamKeyMintedFromAListedKeyMustBeThatKey; with the non-test sources reverted, the tests of the new behavior fail.
• Integration: tests/integration/test_cas_janitor_drain on RustFS, a disk with a batch delete and one with support_batch_delete = false: 2500+ dead keys drain in one deleting round.
• Not measured: the A/B on the RustFS stand from PR 2468 was not repeated for this branch.

Related: #2468

Changelog category (leave one):

• Performance Improvement

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

CAS GC drains a dropped table's reference stream in one round: dead stream keys are deleted in batches on the GC I/O pool, under a soft time budget instead of one page per round.

Documentation entry for user-facing changes

• Documentation written in this PR (docs/en/antalya/cas/architecture/garbage-collection.md, docs/en/operations/system-tables/cas_gc_log.md, docs/en/antalya/cas/configuration.md)

CI/CD Options

Regression jobs to run:

• CAS (content-addressed storage; Antalya only)

[github-actions]

Workflow [PR], commit [a39bccb]