A GC custodian — required, and a serverless deployment has nowhere to put one

Datahike's storage GC (d/gc-storage) must run in a writer JVM. A fully
serverless deployment has nowhere to run one, so today nothing here collects
garbage and the bucket only grows.

This is not an optimisation. Measured on one tenant in the source prototype: 197
objects of which 40 were live after GC — 80% garbage. A third-party production
bucket was found at 16x its live state for want of a custodian.

Constraints that make it non-trivial:

• It has to hold the writer role, and writers are single-writer until #878 —
  so the custodian and the writer function must not be live at the same time on
  the same tenant, or the custodian must be the writer.
• It is per tenant, and the number of tenants is the whole point of the model,
  so it needs a schedule/queue rather than a loop over everything.
• It wants to run when the tenant is idle, which is most of the time in the
  regime where serverless wins at all.

Options to evaluate, cheapest first:

1. A scheduled long-lived container (ECS/Fargate task, Cloud Run job) holding the
   writer role, walking a work queue of tenants — the boring answer, and it
   removes the "no always-on process" property that some of the economics rest on.
   Quantify what that costs.
2. Fold GC into the writer function itself, opportunistically, after a commit,
   with a budget. Attractive because the writer is already the only writer;
   risky because a function has an execution deadline and GC does not.
3. Wait for #878 and let any writer safely GC under CAS.

Whatever is chosen, the README's "Not built, and required" line should become a
description of what actually runs.

Start with the README's “Not built, and required” line and the d/gc-storage behavior described in the issue. Evaluate the scheduled ECS/Fargate option, writer-function integration, and waiting for #878, including the requested cost and concurrency constraints. Done means selecting and documenting what runs per tenant and updating the README accordingly.