Three patches for Lunar Lake (LNL) camera bring-up – SET_HOST_IDENTIFIER, auto-release, sensor_owner sysfs

I got the IPU7 camera fully working on a Dell XPS 13 (Core Ultra 200V, Lunar Lake) running Fedora 42 / kernel 6.18.8, with three patches to the CVS driver. These address the same probe failure reported in #31.

### Hardware

- Dell XPS 13 (hw rev 0x10280cc9)
- Camera: OV02C10 (OVTI02C1:00) on CSI-2 port 0, I2C via usbio-i2c.1
- CVS chip: INTC10DE:00 at 0x76 on usbio-i2c.0
- Protocol 1.0, no magic number support

### Problem

The unmodified driver fails to probe because `SET_HOST_IDENTIFIER` returns -EIO and the driver treats this as fatal. This is the same failure in #31:

```
Intel CVS driver i2c-INTC10DE:00: cvs_common_probe:set_host_identifier cmd failed
```

Once that's fixed, the driver acquires the sensor via the GPIO handshake and the camera works. However, two usability problems remain:

1. The camera LED stays on permanently because nothing releases the sensor after probe.
2. There is no mechanism for userspace to re-acquire the sensor on demand after a release.

### Patches

**1. Make SET_HOST_IDENTIFIER non-fatal**

The GPIO-based sensor acquisition handshake succeeds without this I2C command. On this hardware (and likely all LNL with protocol 1.0), the command consistently returns -EIO via the USBIO I2C bridge. Downgrading to `dev_warn` lets the driver continue to the GPIO handshake.

```diff
ret = cvs_write_i2c(SET_HOST_IDENTIFIER, NULL, 0);
- if (ret) {
- dev_err(cvs->dev, "%s:set_host_identifier cmd failed", __func__);
- goto exit;
- }
+ if (ret)
+ dev_warn(cvs->dev, "%s:set_host_identifier cmd failed (non-fatal)", __func__);
```

**2. Delayed sensor release after probe**

After acquiring the sensor at probe (so dependent sensor drivers like ov02c10 can bind), schedule a release after 10 seconds. This turns the camera LED off when no application is using the camera.

```diff
icvs->icvs_sensor_state = CV_SENSOR_VISION_ACQUIRED_STATE;
acpi_dev_clear_dependencies(ACPI_COMPANION(icvs->dev));

+ INIT_DELAYED_WORK(&icvs->delayed_release, cvs_delayed_release);
+ schedule_delayed_work(&icvs->delayed_release, msecs_to_jiffies(10000));
```

(With a corresponding `delayed_work` field in `struct intel_cvs` and a `cancel_delayed_work_sync` in the remove path.)

**3. `sensor_owner` sysfs attribute for userspace acquire/release**

Exposes a read/write sysfs file so userspace can acquire the sensor before camera use and release it afterwards:

```
echo ipu > /sys/bus/i2c/devices/i2c-INTC10DE:00/.../sensor_owner # LED on, camera usable
echo cvs > /sys/bus/i2c/devices/i2c-INTC10DE:00/.../sensor_owner # shows "ipu" or "cvs"
cat .../sensor_owner # shows "ipu" or "cvs"
```

This is necessary because the camera LED is hardware-tied to the CVS req GPIO – it stays on the entire time the host holds sensor ownership. Without this, users either have no camera (if released) or a permanently-lit LED (if acquired).

### Result

With all three patches, the boot sequence is:
1. CVS probes → acquires sensor → ov02c10 binds to IPU7 ISYS
2. 10s later → sensor auto-released → LED off
3. Userspace writes `ipu` to sysfs → LED on, camera active
4. Userspace writes `cvs` to sysfs → LED off

The camera works at 1920x1080@30fps via libcamera 0.7.0 Simple pipeline handler + GPU-accelerated SoftISP, exposed through PipeWire.

### Note on probe ordering

The upstream kernel has INTC10DE in `acpi_ignore_dep_ids[]` (commit 4405a214df14), so ov02c10 probes before CVS is ready and fails. A udev rule that re-binds ov02c10 after CVS probes works around this. Antti Laakso's pending patch ("media: ipu-bridge: Add DMI quirk for CVS-sensor dependency") should fix this properly.

Full writeup with ACPI topology, INT3472 details, and upstream references: available on request.