Bugfix: Propagate dynamic range and image format diffs to CameraSystem

[Kimblebee]

TLDR:
🐛 Problem: Currently, when settings are updated from SettingsRepository, CameraAppSettings.applyDiffs propagates changed preferences to CameraSystem. It currently omits dynamicRange and imageFormat.
✅ Solution: this PR includes dynamicRange and imageFormat in CameraAppSettings.applyDiffs tests.
❓ note: HDR controls aren't currently included in JCA's dedicated settings screen.

Longer description:

• ⭐ Adds diff propagation for dynamicRange and imageFormat in CameraAppSettings.applyDiffs.
• Adds unit tests in CameraSystemTest verifying applyDiffs correctly updates CameraSystem on setting changes and skips unchanged settings.
• Adds unit tests in PreviewViewModelTest confirming end-to-end propagation from SettingsRepository through applyDiffs to CameraSystem.
• Adds parameterized on-device tests in CameraSystemApplyDiffsDeviceTest executing across all available lenses (BACK, FRONT), verifying live diff application and skipping gracefully when unsupported by hardware constraints.

[gemini-code-assist]

Code Review

This pull request adds support for propagating dynamicRange and imageFormat changes in CameraSystem.applyDiffs, accompanied by new unit and instrumented tests to verify the behavior. The review feedback suggests restricting the visibility of the new test classes to internal to align with the repository's style guide, and using distinctUntilChanged() on the settings flow in the instrumented tests to prevent potential flakiness.

[gemini-code-assist]

According to the repository style guide, all new classes should use the most restrictive visibility modifier possible. Since this test class does not need to be publicly accessible, it should be declared as internal.

Suggested change

	class CameraSystemApplyDiffsDeviceTest(private val lensFacing: LensFacing) {
	internal class CameraSystemApplyDiffsDeviceTest(private val lensFacing: LensFacing) {

References

1. Proper Visibility Modifiers: Ensure all new functions, properties, and classes use the most restrictive visibility modifier possible (e.g., private, internal) while still allowing necessary access. Avoid public visibility unless explicitly required for external API exposure. ^(link)

[gemini-code-assist]

To prevent potential flakiness and avoid buffering duplicate values in the channel (e.g., if other unrelated settings change and trigger emissions), it is recommended to use distinctUntilChanged() on the flow before producing the channel.

Suggested change

	val dynamicRangeCheck = cameraSystem.getCurrentSettings()
	.filterNotNull()
	.map { it.dynamicRange }
	.produceIn(this)
	val dynamicRangeCheck = cameraSystem.getCurrentSettings()
	.filterNotNull()
	.map { it.dynamicRange }
	.distinctUntilChanged()
	.produceIn(this)

[gemini-code-assist]

To prevent potential flakiness and avoid buffering duplicate values in the channel (e.g., if other unrelated settings change and trigger emissions), it is recommended to use distinctUntilChanged() on the flow before producing the channel.

Suggested change

	val imageFormatCheck = cameraSystem.getCurrentSettings()
	.filterNotNull()
	.map { it.imageFormat }
	.produceIn(this)
	val imageFormatCheck = cameraSystem.getCurrentSettings()
	.filterNotNull()
	.map { it.imageFormat }
	.distinctUntilChanged()
	.produceIn(this)

[gemini-code-assist]

According to the repository style guide, all new classes should use the most restrictive visibility modifier possible. Since this test class does not need to be publicly accessible, it should be declared as internal.

Suggested change

	class CameraSystemTest {
	internal class CameraSystemTest {

References

1. Proper Visibility Modifiers: Ensure all new functions, properties, and classes use the most restrictive visibility modifier possible (e.g., private, internal) while still allowing necessary access. Avoid public visibility unless explicitly required for external API exposure. ^(link)