Camera: Pan, Tilt, Gain, and BacklightCompensation have no CameraControl variant, so no backend can expose them

While probing a Logitech C930e on Windows I found four device-supported UVC controls that `CameraControl` has no variant for. They are not missing from one backend — the shared vocabulary in `crates/openlogi-camera/src/controls.rs` has no name for them, so no backend can expose them.

Reporting the device's own numbers rather than a wishlist. From an independent DirectShow probe (raw property ids, no OpenLogi code in the path):

```
[IAMCameraControl]
Pan min=-10 max=10 step=1 default=0 caps=0x2
Tilt min=-10 max=10 step=1 default=0 caps=0x2
Roll UNSUPPORTED
Zoom min=100 max=400 step=1 default=100 caps=0x2 (mapped)
Exposure min=-11 max=-2 step=1 default=-5 caps=0x3 (mapped)
Iris UNSUPPORTED
Focus min=0 max=255 step=5 default=0 caps=0x3 (mapped)

[IAMVideoProcAmp]
Brightness / Contrast / Saturation / Sharpness (mapped)
Hue UNSUPPORTED <- so `Tint` is correctly absent here
Gamma UNSUPPORTED
ColorEnable UNSUPPORTED
WhiteBalance min=2000 max=7500 step=1 default=4000 caps=0x3 (see #662)
BacklightCompensation min=0 max=1 step=1 default=0 caps=0x2
Gain min=0 max=255 step=1 default=0 caps=0x2
```

So: **Pan, Tilt, BacklightCompensation, Gain** are supported by the hardware and unreachable through OpenLogi. Pan/tilt is a headline feature of this camera — zoom already works, so the panel shows one third of a PTZ control set.

## The seam already exists and the compiler enforces it

Worth saying because it makes the smaller half of this cheap: `controls.rs` is the OS-generic vocabulary, and all three backend mappings are exhaustive with no catch-all arm (`uvc.rs`, `uvc_linux.rs`, `uvc_windows.rs`). Adding a variant to `CameraControl` therefore fails to compile until every backend maps it — no silent per-OS gaps.

## Two clean halves, very different costs

**Gain and BacklightCompensation are cheap and symmetric.** All three platforms model them as ordinary scalar properties:

| control | UVC selector | V4L2 | DirectShow |
|---|---|---|---|
| Gain | `PU_GAIN_CONTROL` | `V4L2_CID_GAIN` | `VideoProcAmp_Gain` (9) |
| BacklightCompensation | `PU_BACKLIGHT_COMPENSATION_CONTROL` | `V4L2_CID_BACKLIGHT_COMPENSATION` | `VideoProcAmp_BacklightCompensation` (8) |

**Pan/Tilt is not symmetric, and the cost lands entirely on macOS.** Windows exposes `CameraControl_Pan` and `CameraControl_Tilt` as two independent properties, and V4L2 has `PAN_ABSOLUTE` / `TILT_ABSOLUTE` — but raw UVC carries both in a single `CT_PANTILT_ABSOLUTE_CONTROL` whose payload is two 4-byte signed values. `uvc.rs`'s `Payload` enum is `U16 | I16 | U32` — there is no 8-byte variant — so two generic controls would have to share one selector with a read-modify-write of half the struct.

I would suggest splitting those: Gain + BacklightCompensation as a small change, Pan/Tilt as its own with the `Payload`/UVC work scoped properly. Happy to do either or both if the shape is agreed — I have a C930e to test the Windows side against, but no macOS hardware, so the UVC half would need someone who does.

## Environment

- Windows 11 Pro 25H2 (26200.8973), x86_64
- Logitech Webcam C930e (`046d:0843`)
- Built from `master` at `822c6e4`

Start with the shared CameraControl vocabulary in crates/openlogi-camera/src/controls.rs, then inspect the exhaustive mappings in uvc.rs, uvc_linux.rs, and uvc_windows.rs. Check the Payload enum and the platform control constants before deciding how the scalar controls and pan/tilt fit together. Run the project’s checks to confirm every backend maps the new controls and that supported camera properties are reachable without compilation gaps.

Written by the indexing model from the issue text.