Cloud-readiness: move audio file storage off local disk to object storage

## Problem

Audio files are written to and served from the local filesystem of the `audio-file-uploader` process, so the service cannot run with more than one instance.

- `apps/audio-file-uploader/src/app/app.module.ts:17` — multer `diskStorage` writes to `${FILESERVER_PATH}/uploads`
- `apps/audio-file-uploader/src/app/fileUpload/fromYoutube/UploadFromYoutubeService.ts:12` — ffmpeg output goes to the same local directory
- `apps/audio-file-uploader/src/app/fileUpload/FileUploadService.ts:27` and `UploadFromYoutubeService.ts:67` — the public URL is hand-built from `AUDIO_FILE_SERVER_BASE_URL`, i.e. there is exactly one file server
- `apps/audio-file-uploader/src/app/app.module.ts` — `ServeStaticModule` serves the bytes from the same process

A file uploaded through instance A returns 404 on instance B. A load balancer does not fix this; it requires a shared blob store.

## Proposed rework

- Stream uploads directly to object storage (GCS/S3) instead of local disk
- Serve via signed URLs or a CDN origin rather than `ServeStaticModule`
- Keep the URL shape stable, or plan a migration: tracks persisted in Firestore store an **absolute** URL, so existing rows need rewriting

## Scope note

This is one half of the ingestion rework; the other half is the job pipeline (see the related issue). Neither works behind a load balancer on its own.