[Milestone] Prepare tb-dev for legacy-stage Stalwart migration (v0.15.x → v0.16.x)

Overview

This milestone tracks preparing the tb-dev environment to receive a migration from our legacy Stalwart v0.15.x installation ("mailstrom" / legacy-stage) to a Kubernetes-backed Stalwart v0.16.x deployment. This is not just a platform move -- it crosses a schema-breaking version boundary, so the target must be fully prepared before any data-migration steps are executed.

Context

• Source: Legacy Stalwart v0.15.x (legacy-stage), with blob storage in S3 (~2.5 GB across ~1M object versions)
• Target: Stalwart v0.16.x on EKS (tb-dev), using a new S3 bucket, Redis as the in-memory store, and OIDC auth against tb-dev/accounts
• Strategy: Downtime-tolerant migration -- prepare the target and replicate blob data cross-account first, then execute a short cutover window. The cutover procedure itself is tracked separately.

Scope (sub-issues to follow)

1. Create new S3 bucket with ACK in thundermail-deploy (second bucket, set up for sync later)
2. Add permissions for stalwart-server to use this bucket (Pulumi config in platform-infrastructure)
3. Write/apply NDJSON file for initial v16 setup -- blob store (mzla-eks-tb-dev-stalwart-blob-storage), memory store, auth, SSL certs, listeners, network settings (NDJSON format docs). Establish a pattern of using NDJSON files to codify new environments' initial configuration state.
4. Establish cross-account S3 object replication -- IAM policy in legacy, bucket policy on the new tb-dev bucket, replication rule on the legacy blob store bucket
5. Execute a batch operation to replicate all existing files into the destination bucket and wait for completion

Out of Scope

• The actual cutover/migration execution procedure -- separate issue
• Preparing tb-prod for the legacy-prod migration -- separate milestone