Changing listening languages during a recording changes that recording instead of the next dictation

## Problem

Changing the listening-language setting while a dictation is recording immediately changes the recognition options for that dictation. In a multi-piece dictation, pieces can therefore run under different user profiles depending on when the setting changes. The pipeline and its settings wiring both specify that language changes take effect on the next dictation.

## Evidence

Reviewed main commit `8d93f5b8574f3c7b8c30086d9c817bf7f5d4827d`.

- `Sources/UttrflowPipeline/DictationPipeline.swift:130-133`: `adopt(profile:)` replaces the shared profile immediately.
- Lines 142-143: `takeSettings()` snapshots only the cleaner and destination overrides.
- Line 580: each recognition window reads the mutable shared profile to compute its language hint.
- `Sources/Uttrflow/AppDelegate.swift:1741-1744`: profile changes are forwarded to `adopt` without waiting for an active dictation to finish; the comment explicitly promises the next dictation.

Release-mode reproduction using the unchanged production pipeline and injected speech/capture doubles:

1. Construct the pipeline with the English profile and a long early-poll interval.
2. Call `startRecording()`.
3. Call `adopt(profile: UserProfile(preferredLanguages: [.hindi]))` while recording.
4. Call `finishRecording()` and inspect the speech-engine request.

The single recognition call receives `.hindi` as its language hint. The original English profile would have supplied `nil` for that first piece. This confirms a request-policy change during the active recording, without claiming a particular real-model transcription result.

The existing `DictationPipelineLanguageTests.adoptsTheProfile` changes the profile before recording begins, so it does not protect this boundary. `DictationPipelineSettingsTests.settingsLandOnTheNextDictation` covers mid-recording changes only for cleaner/destination settings.

## Fix and acceptance criteria

Include the profile in the settings captured when a dictation or retry begins, and use that captured profile throughout recognition and cleaning for that attempt. Keep subsequent settings available for the next attempt.

Add a regression test that changes the profile after recording starts: the current recording must use its original profile and the next must use the new one. Cover a multi-piece recording so all its pieces use the same profile snapshot. Preserve the existing English, Hindi-only and mixed-language hint policies; this issue concerns when a setting takes effect, not what those policies should be.

Priority: P2. Reproduced with a release-mode test; production files unchanged.

Start with Sources/UttrflowPipeline/DictationPipeline.swift, especially adopt(profile:), takeSettings(), and the recognition-window logic around line 580; review AppDelegate.swift:1741-1744 for the intended timing. Extend the existing DictationPipelineLanguageTests and DictationPipelineSettingsTests with a mid-recording profile change, including multiple pieces, and verify the current attempt keeps its original profile while the next uses the new one.

Written by the indexing model from the issue text.