Camera setters read-modify-write full parameters, turning drone-side effective values into sticky requests #222

Camera property setters (e.g. Camera.streaming_protocol, Camera.stream_resolution) update settings by read-modify-write: _update_camera_parameters() → mutate one field → SetCameraParameters with the full parameter set. Every unrelated field the drone reported becomes an explicit request.

This turns any server-side effective-value reporting into a sticky setting. Concrete case (bench-reproduced on an Ultra, gst_rtsp_record#308): with the MJPEG 1080p stream cap, switching protocols via the SDK reads the clamped stream_resolution: 1080 and sends it back as a request — the user's 4K stream choice is silently overwritten and stays 1080p after leaving MJPEG mode, until re-set. (On firmware ≥ the gst_rtsp_record#311 read-back work, recording resolution round-trips correctly; the stickiness is stream-only. See the analysis and correction in gst_rtsp_record#308.)

Suggested fix: setters send only the field being changed and UNSPECIFIED/0 for the rest — the protocol already defines those as "leave as is" (p2_drone resolves 0/UNSPECIFIED to fallbacks). That makes SDK writes intent-preserving regardless of what the drone reports as applied values.