[ianperry95]

Problem

Cloud sync only works through ChurchApps. Anyone who doesn't have a ChurchApps account, or who wants their data in storage they control, has no way to sync shows and settings between machines.

Change

Adds S3 compatible storage as a second cloud sync provider in the Files tab. It works with any S3 compatible bucket: AWS S3, Cloudflare R2, Backblaze B2, MinIO, Wasabi and others. You enter endpoint, region, bucket, an optional folder, access key and secret key, then turn on sync the same way as ChurchApps.

The provider stores the same current.zip / previous.zip pair the ChurchApps sync uses. All merge logic stays in syncManager.ts, behind a small new SyncProvider interface, so S3 goes through the same ledger, stale merge guard and weekly backup.

• What syncs doesn't change. Shows, the portable Config stores, Bibles and media metadata. Media files still aren't synced, same as today.
• No new dependency. The S3 client is small and has its own SigV4 signer. It only covers the calls sync needs (HEAD, GET, PUT, plus a connection test).
• One provider at a time. Live presence and the settings socket stay ChurchApps only. createCloudSocket returns early for S3.
• Credentials: Connect tests the bucket before saving anything. The config goes in the ACCESS store under secrets.s3Sync. The secret key never goes back to the renderer, and leaving the field empty when editing keeps the stored one.
• ETag cache: the last synced zip is kept with its ETag in userData/cloud-cache. A sync where nothing changed in the cloud skips the download.
• Path style defaults to on when a custom endpoint is set, since most non-AWS services need it.
• Error text from the storage server is HTML-escaped before it reaches the alert popup. The popup renders HTML, so a bad or intercepted endpoint could otherwise inject markup.

Files

• src/electron/cloud/s3/S3Client.ts, sigv4.ts, S3Error.ts: the S3 client and request signing, with tests
• src/electron/cloud/S3SyncManager.ts: the provider, config storage and ETag cache
• src/electron/cloud/syncManager.ts: the SyncProvider interface and the s3 registration
• src/frontend/components/settings/tabs/CloudSyncS3.svelte: the connection form
• src/frontend/components/settings/tabs/CloudSyncOptions.svelte: Read only, Media sync folder and Restore weekly backup, moved here so both providers share them
• src/frontend/components/settings/tabs/Files.svelte: uses the two components above
• src/frontend/utils/cloudSync.ts, save.ts: S3 setup and sync triggers on autosave and close
• src/electron/IPC/responsesMain.ts, src/frontend/IPC/responsesMain.ts, src/types/IPC/Main.ts: config get/set over IPC
• public/lang/en.json: cloud.s3* strings

The ChurchApps section of Files.svelte shows a diff from the move into CloudSyncOptions.svelte. Its behaviour shouldn't change.

Testing

• vitest run on src/electron/cloud: 61 passed, including the new SigV4 and S3 client tests
• Prettier: clean on the changed files
• Manual, in an unsigned Windows build connected to a real bucket: the first sync uploaded current.zip. I deleted a show while the app was closed, changed the machine ID and reopened. The startup sync pulled the show back down, so the new-device path works end to end.

Not tested: two physical machines editing and deleting against the same bucket, the weekly previous.zip restore, and svelte-check.