Harden audio pipelines and reduce VibeVoice memory

[jvogan]

Summary

• bound decoded audio size, format, playback queue, and export work
• harden file destinations and preserve existing outputs on failed exports
• reduce VibeVoice conditioning and scheduler memory without changing numerical behavior
• add focused admission, resource-bound, destination-safety, and equivalence tests

Validation

• public repository audit, secret scan, and history scan
• full public validation gate
• 28 focused audio and VibeVoice tests
• 54 macOS application tests

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1cb93fa3aa

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Avoid rejecting long concatenated exports

When project export uses concatenated mode, ProjectAudioExportCoordinator still calls concatenatedBuffer before audioPipeline.export (apps/ValarTTSMac/Sources/ValarTTSMacApp/Projects/ProjectAudioExportCoordinator.swift:136-148). This new 64 MiB check makes concatenate return nil for otherwise-compatible audio over about 11.6 minutes of mono 24 kHz float32 audio, or about 5.8 minutes stereo, surfacing as ProjectAudioExportError.incompatibleBuffers before WAV/M4A export can run. Either route those exports through a streaming writer before applying this cap or keep the full-buffer path available for long projects.

Useful? React with 👍 / 👎.