Function player_set_stream_quality 

pub async fn player_set_stream_quality(
    player: State<'_, PlayerStateWrapper>,
    repository_manager: State<'_, RepositoryManagerWrapper>,
    repository_handle: String,
    quality: StreamingQuality,
    use_html5: bool,
    current_position: Option<f64>,
    media_source_id: Option<String>,
    audio_stream_index: Option<i32>,
) -> Result<StreamQualityResponse, String>

Change the bandwidth ceiling of the video that is playing right now.

A cap is a property of the stream the server is producing, so unlike a volume change it cannot be applied to a stream already in flight — the stream has to be re-opened at the new quality and resumed at the current position. That is the same reload the transcoded-seek and audio-track paths use, and the same two-sided split: HTML5 gets the URL back and reloads its own element, while a native backend is reloaded here.

The change applies to this playback only. The in-player picker is a “this film, this connection” control and its doc has always said so, but it used to be implemented by writing the process-wide ceiling — so choosing 2 Mbps to get one awkward film moving silently capped every video played afterwards for the rest of the process, with the Settings screen still showing the old value and nothing in the UI admitting the change. It now sets a per-playback override that the next item clears; the durable default belongs to Settings, and player_set_video_settings is the one that writes to the database.

TRACES: UR-074, UR-079 | DR-162, DR-226