Automatic TTS playback stops early or does not start across app run modes

### Self Checks

- [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542).
- [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general).
- [x] I have searched for existing issues, including closed ones.
- [x] I confirm that I am using English to submit this report.
- [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
- [x] Please do not modify this template :) and fill in all the required fields.

### Dify version

1.16.0

### Cloud or Self Hosted

Self Hosted (Docker)

### Steps to reproduce

1. Create a Chatflow, Workflow, or Completion app whose response is long enough to produce multiple streamed TTS chunks.
2. Enable text-to-speech and set automatic playback to enabled.
3. Run the app from app debugging, full-screen preview, WebApp, or Explore.
4. Wait for the streamed response and audio playback to complete.
5. While audio is still streaming, stop the run or start another run.
6. Repeat the test in Chrome, Safari, or Firefox.

### ✔️ Expected Behavior

Automatic TTS playback should:

- Start from the user's send or run action.
- Play every streamed audio chunk in order.
- Finish only after the final audio event.
- Stop when the current run is stopped.
- Use only the current audio stream on subsequent runs.
- Behave consistently across supported app run modes.

### ❌ Actual Behavior

The observed behavior varies by app surface:

- Automatic playback may not start.
- Playback may stop after only the first few seconds.
- Trailing audio chunks may be lost.
- A stopped or replaced run may leave stale player callbacks that affect a later run.

The issue has two related lifecycle causes:

1. The backend can emit `workflow_finished` before queued TTS chunks and the audio end event, causing the SSE consumer to stop too early.
2. Frontend entry points do not consistently prepare, own, replace, and destroy the automatic audio player across the complete run lifecycle.

These are parts of the same automatic-playback contract rather than separate browser-specific decoding issues.

Trace the backend SSE consumer around the workflow_finished event and the frontend automatic audio-player lifecycle across app debugging, full-screen preview, WebApp, and Explore. Reproduce a long streamed response, then stop and replace runs in the listed browsers. Done means playback starts from the run action, preserves every chunk through the final audio event, and leaves no stale callbacks.

Written by the indexing model from the issue text.