Main-Screen Media Settings Affect Existing Content and Retries: Intended Behavior?

## Summary

The main-screen media controls appear to behave as global runtime state, affecting both new and previously generated content.

I’m opening this to clarify whether this is intentional product design or unintended behavior, especially since the app already provides a separate Settings panel for provider configuration.

Currently, it is unclear which surface is the source of truth:
- the main-screen media popover
- or the dedicated Settings panel

## Observed behavior

Changes made in the main-screen media popover affect previously generated content as well.

Examples:

### 1. Media retry uses the current main-screen provider
If a generated image placeholder failed earlier, and I later switch the image provider on the main generation screen (for example from `seedream` to `grok-image`), retry behavior appears to follow the current main-screen provider instead of the provider context that existed when the content was originally generated.

### 2. TTS toggle affects previous lectures too
If I disable TTS from the main generation screen, audio is also disabled for previously generated lectures/classroom content, not just for future generations.

### 3. Changing provider during new generation affects earlier content
If I start generating new content with a different media/TTS provider (for example ElevenLabs instead of browser/default TTS), existing/earlier lecture content can also start failing, even though that earlier content was originally generated under the browser/default setup.

### 4. Main-screen controls seem to override the separate Settings panel
The app already has a dedicated Settings dialog for provider configuration and selection, but behavior seems to follow the current values from the main-screen media popover for retries / playback / generated content behavior.

As a result, it is unclear whether:
- the Settings panel is meant for persistent provider configuration only
- or the main-screen media popover is meant to be the effective source of truth for active runtime behavior

## Why this is confusing

There seem to be two possible product models:

### Option A: Global runtime controls
Main-screen media settings are intentionally global.
That would mean:
- retries use the currently selected provider
- existing classroom playback follows current TTS/media toggles
- changing provider/toggles can affect older content too
- the main-screen popover is the active runtime controller, even if providers are also configured in the Settings panel

### Option B: Generation-scoped controls
Main-screen media settings only apply to newly generated content.
That would mean:
- retries for older media use the provider/model originally associated with that content/task
- previously generated lectures keep their original playback/media behavior
- changing provider/toggles only affects future generations
- the separate Settings panel remains the source of truth for configured providers without retroactively changing older generated content

Right now the app seems closer to Option A, but it is not obvious from the UI whether that is intentional.

## Reproduction examples

### Example 1: Retry path
1. Generate content with image placeholders
2. Let image generation fail
3. Change the image provider in the main-screen media popover
4. Retry the old failed placeholder
5. Observe that retry follows the current provider selection

### Example 2: TTS toggle
1. Generate a lecture/classroom with TTS available
2. Return to the main generation screen
3. Disable TTS in the media popover
4. Go back to previously generated lecture content
5. Observe that audio/TTS is now disabled there too

### Example 3: Switching provider for new generation
1. Generate earlier lecture content using browser/default TTS or initial default media setup
2. On the main generation screen, switch to another provider for a new generation (for example ElevenLabs)
3. Go back to older generated content
4. Observe that older content behavior can now depend on the newly selected provider/toggles, including failures

### Example 4: Settings panel vs main-screen popover
1. Configure providers in the dedicated Settings dialog
2. Change media/TTS-related controls from the main generation page popover
3. Retry failed media or interact with existing classroom content
4. Observe that behavior appears to follow the current main-screen state
5. It is unclear whether this is expected, given the separate Settings panel

## Question

Is this expected design, or should media/TTS behavior be scoped per generated content?

More specifically:
- Should main-screen media settings act as global runtime controls (affecting existing content and retries)?
- Or should they apply only to newly generated content, with existing content retaining its original provider/toggle context?

## Suggested clarification

If the current behavior is intentional, it would help to document that the main-screen media controls act as global runtime settings and can affect existing content and retries, even when a separate Settings panel exists.

It may also improve clarity to reflect the currently active provider/model in the Settings panel (or otherwise indicate which configuration is actively in use), so it is clear which settings are actually driving runtime behavior.

If it is not intentional, then media/TTS behavior may need to be scoped more explicitly:
- current controls affect only future generation
- retries use original task/provider context or offer an explicit "retry with current provider" choice
- existing lecture playback remains stable
- the roles of the main-screen popover vs the Settings panel are clarified

Happy to help implement whichever direction is preferred.