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.

Start by examining the file upload services in apps/audio-file-uploader/src/app/fileUpload/. The multer configuration in app.module.ts uses diskStorage. Research how to replace this with a storage driver for S3 or GCS. You'll need to update the URL generation logic in FileUploadService.ts and UploadFromYoutubeService.ts to use signed URLs. Check Firestore for existing track records to understand the data migration needed for absolute URLs.

由索引模型根据 Issue 内容生成。