psys: r78 writes to struct ipu7_bus_device fields absent from the in-kernel intel_ipu7 (ABI break for DKMS builds)

Since the 2026-06-29 drop (`0e8c71a`, released as r76/r78), the out-of-tree psys driver is ABI-incompatible with an in-kernel `intel_ipu7`, and the failure is silent: `/dev/ipu7-psys0` never appears and the RGB camera is gone.

## The change

`0e8c71a` appends two fields to `struct ipu7_bus_device` in `drivers/media/pci/intel/ipu7/ipu7-bus.h`:

```c
struct mutex acquire_fw_task_buffer_lock;
unsigned int (*get_running_fw_task_count)(struct ipu7_bus_device *adev);
```

`ipu7_psys_probe()` writes to the second:

```c
adev->get_running_fw_task_count = ipu7_psys_get_running_fw_task_count;
```

and `ipu_psys_task_request()` takes the new mutex.

## Why that breaks

`struct ipu7_bus_device` is allocated by `intel_ipu7`. On any distro shipping the **staging** `intel_ipu7` with the kernel while psys comes from **DKMS**, the two disagree about the struct:

```
intel_ipu7 kernel/drivers/staging/media/ipu7/intel-ipu7.ko.zst
intel_ipu7_psys updates/dkms/intel-ipu7-psys.ko.zst
```

The kernel allocated the shorter struct; the DKMS psys was compiled against the longer one. So the probe-time assignment writes past the end of the allocation, and the mutex lock operates on memory that is not a mutex.

Verified against the running kernel module: `intel-ipu7.ko` contains `ipu7_bus_ready_to_probe` — a field of the same struct — and zero occurrences of either new field.

## Reproduced

Two machines, independently:

* Dell XPS 16 DA16260, Panther Lake, CachyOS 7.2.0-rc4 — pinned at r74 (`24d8923`), works. r76 previously produced a runtime `psys_ioctl` GPF here.
* Dell (reporter), CachyOS 7.1.4 — r78, `/dev/ipu7-psys0` MISSING after a clean rebuild and reboot, `intel_ipu7_psys` loaded, no RGB camera. Details in #26.

This affects every Arch/CachyOS user on a recent kernel, since the staging `intel_ipu7` landed in-tree while psys did not.

## Related, same root cause

`ipu7_psys_probe()` also begins:

```c
if (!adev->isp->ipu7_bus_ready_to_probe)
return -EPROBE_DEFER;
```

That is a *read* of a field on the same kernel-owned struct, and it fails the same way when the layouts disagree — psys defers forever while isys binds normally, because isys ships alongside `intel_ipu7`. That asymmetry makes the failure look selective and sends people debugging the wrong component entirely.

## Suggestions

The out-of-tree psys reaching into a struct owned by a module it does not build alongside is fragile by construction. Options that would help:

1. **Version the interface.** A version field or a size check on `struct ipu7_bus_device`, so a mismatched psys refuses to probe with a clear message instead of corrupting memory.
2. **Keep new state in psys.** `get_running_fw_task_count` and the FW-task mutex are psys concerns; storing them on the shared bus device is what creates the coupling.
3. **Document the constraint.** If the vendor tree is only supported when `intel_ipu7` is *also* built from it, saying so in the README would save people a lot of time — the current failure gives no hint.

Happy to test patches; I have the hardware and a reproducer on two machines.

Start by reading drivers/media/pci/intel/ipu7/ipu7-bus.h, ipu7_psys_probe(), and ipu_psys_task_request(), then compare the struct layout used by intel_ipu7 and the DKMS psys module. Reproduce the missing /dev/ipu7-psys0 device on the reported kernel versions. Done means the modules handle an interface mismatch safely and psys either probes correctly or reports a clear failure.

Written by the indexing model from the issue text.