Store recognition results per STT entity and consume on use

[jgsaez9]

Problem

The recognised speaker was stored in a single shared hass.data slot (speaker_recognition.last_result). Two issues follow:

1. Multiple satellites collide. With more than one satellite/pipeline active, concurrent utterances overwrite the single slot, so a conversation turn can be enriched with another satellite's speaker.
2. Stale reuse. The value was never cleared, so a turn with no fresh recognition could still be enriched with a result from up to 5 seconds earlier.

Fix

• The STT proxy stores results keyed by its entity_id (hass.data[DOMAIN]["results"][entity_id]).
• The conversation proxy selects the freshest result within the freshness window and consumes it (removes it), so a recognition is applied to at most one turn and stale results are never reused.

This does not fully correlate a specific satellite's audio to its conversation turn (Assist does not expose a shared run id to both the STT and conversation entities), but it removes the shared-slot overwrite and the stale-reuse window, which are the practical failure modes.