Make cohort processor disaster recovery real before downstream depends on membership state

All membership evaluation state lives in RocksDB on a single pod's local volume. Losing that volume today means rerunning backfills, which is annoying but harmless because nothing consumes the output yet. Once the cohort_membership Postgres table feeds workflows or feature flags, a lost volume becomes a long outage while state rebuilds.

The processor has an S3 checkpoint and restore layer, but it is off by default (CHECKPOINT_ENABLED in rust/cohort-stream-processor/src/config.rs), has never run in production, and no bucket or access role is provisioned.

Known defects to fix before enabling it. There is no periodic full upload, so a checkpoint can reference arbitrarily old files and a bucket retention policy would delete files a restore still needs, silently breaking recovery. A failed restore logs a warning and cold starts with an empty store instead of alerting. Enabling checkpoints without configuring a bucket silently does nothing. There is no metric for bytes uploaded, so cost cannot be sized.

Fix the defects, provision the bucket and access, then run a restore drill and verify that a pod restored from S3 serves correct membership.

Start in rust/cohort-stream-processor/src/config.rs and trace the S3 checkpoint and restore entry points, including how restore failures and missing bucket configuration are handled. Check the existing RocksDB state flow and metrics setup before making changes. Done means checkpoint retention is safe, failures alert, upload bytes are measurable, access is provisioned, and a restore drill verifies correct membership from S3.