fix(speech-to-text): write the transcoded .wav under tmp/ like the extension

[cabljac]

The extension named the transcoded WAV after the local temp file it had just written, so the object landed at tmp/<original path>.wav under OUTPUT_STORAGE_PATH. The kit named it after the input object instead, so migrated users could not find their transcoded audio.

This restores the extension's paths for both outputs. Because the Speech API output was named after the uploaded object, putting tmp/ back also moved the .txt, so transcribeAndUpload now takes an explicit transcript object name and the handler strips the segment back off, exactly as the extension did. path.posix.join supplies the normalisation path.join(os.tmpdir(), filePath) gave for free.

One deviation, and it needs a decision: a trailing slash on OUTPUT_STORAGE_PATH is stripped rather than doubled. The extension's transcriptions//tmp/a.mp3.wav is a valid object name but not a valid Speech API audio URI, so that config uploaded the audio and never wrote a transcript, leaving the Firestore document on "Transcoding audio file.". #3140 chose parity "double slash included"; that would reproduce a total failure, so this reverses that half.

Verified on a live deploy (three instances, one bucket): all six paths are as documented above, with real transcripts. The double-slash failure and its fix were both observed there, not inferred. vitest run (44 tests), tsc --noEmit and prettier pass.

Fixes #3140

[gemini-code-assist]

Code Review

This pull request restores the legacy behavior of writing transcoded ".wav" files to a "tmp/" subpath (e.g., "tmp/.wav" or under "OUTPUT_STORAGE_PATH" when set). It also removes trailing-slash normalization for "OUTPUT_STORAGE_PATH", matching the legacy extension's behavior. The CHANGELOG, README, implementation in "handlers.ts", and corresponding tests have been updated accordingly. No review comments were provided, so there is no additional feedback.

[IzaakGough]

Pushed fixes for all four points in 5222924, and merged kits in since the branch was a way behind. Resolving the threads.

The transcript was the substantive one: transcribeAndUpload now takes an explicit transcript object name and the handler strips the tmp/ segment it added, so the .wav and the .txt both land where the extension put them. The object path is built with path.posix.join for the normalisation, and there is a comment naming the tmp/ segment as deliberate parity.

The README section is now a table covering both outputs across the unset, transcriptions and transcriptions/ cases. The CHANGELOG entry names both outputs, and I folded the old #3026 line into it, since that line said the .txt keeps tmp/ and this change reverses it. Happy to split them back out if you would rather keep the history separate.

Two legacy quirks are left alone and called out in the description: an OUTPUT_STORAGE_PATH containing its own tmp/, and an object name climbing above tmp/ more than once.

[IzaakGough]

Tested this on a live deploy, and it turned up one thing that changes the decision in #3140. Deployed three instances against one bucket so a single upload exercised all three prefix cases, on us-central1 with a real 6 second speech clip.

The tmp/ parity works exactly as intended for an unset prefix and for transcriptions, transcripts included. The trailing-slash case does not:

3 INVALID_ARGUMENT: Audio URI `gs://<bucket>/transcriptions//tmp/clip.wav.wav` is an invalid GCS path.

Cloud Storage accepts the double-slash object name, so the transcode uploads fine and the failure only lands at the recognition call. The result is an orphaned .wav, no transcript, and a Firestore document stuck on "Transcoding audio file.". The extension passed the same URI to the same API, so it failed the same way, which means no trailing-slash install has ever had a working transcript to stay compatible with. The kit's trailing-slash strip, which this PR had removed, was the only reason that config worked.

So 103cf4e puts the strip back and keeps everything else. After that, all three configs succeed. Worth noting the path.posix.join change is load-bearing for the same reason: an object named audio//clip.mp3 would hit the identical error, and now normalises instead.

Happy to be talked out of it if the double slash matters to someone, but as it stands parity there means reproducing a hard failure.