ov08x40 stuck at "waiting for fwnode graph endpoint" on kernel 7.2.x (Panther Lake / OVTI08F4) — works on 7.1.x

## Summary

On kernel 7.2.x the out-of-tree `ipu-acpi` no longer produces the sensor's fwnode graph endpoint, so `ov08x40` sits in deferred probe forever and never reaches the ISYS media graph. The exact same setup works on 7.1.8. Booting the in-tree staging driver instead gets the sensor bound — which points at `ipu-acpi` rather than at the sensor driver or the bridge concept.

This is a clean 7.1 → 7.2 regression boundary, which I did not find in #79 / #63 / #93 (see "Relation to existing issues" below).

## Environment

| | |
|---|---|
| Machine | Dell XPS 16 DA16260, Core Ultra X7 358H (Panther Lake), BIOS 1.10.1 |
| Sensor | OV08X40, ACPI `OVTI08F4:00`, behind Synaptics SVP7500 (`06cb:0701`) |
| Distro | Arch Linux (Omarchy 4.0.3), `intel-ipu7-camera` 1.0.5 |
| Driver source | ipu7-drivers 1.0.5 (DKMS), built cleanly for every kernel below |
| Kernels | `linux-ptl` 7.1.8-arch1-2 (works) vs 7.2.3-arch1-1 (broken); stock 7.2.3-arch1-3 behaves the same as 7.2.3-ptl |

## Symptom on 7.2.3

`ov08x40` binds to nothing and stays deferred:

```
# cat /sys/kernel/debug/devices_deferred
i2c-OVTI08F4:00 ov08x40: waiting for fwnode graph endpoint
```

The IPU7 side comes up and even reports the sensor, but ISYS never binds it:

```
intel-ipu7 0000:00:05.0: Found supported sensor OVTI08F4:00
intel-ipu7 0000:00:05.0: Connected 1 cameras
intel-ipu7 0000:00:05.0: CSE authenticate_run done
intel_ipu7_psys.psys intel_ipu7.psys.40: IPU psys probe done.
ov08x40 i2c-OVTI08F4:00: supply dovdd not found, using dummy regulator
<- nothing further; no "bind ov08x40", no "All sensor registration completed."
```

`media-ctl -p -d /dev/media0` shows 36 entities (ISYS Capture 0-31 + CSI2 0-3) and **no** `ov08x40` entity. `/sys/bus/i2c/devices/i2c-OVTI08F4:00/software_node` exists, so something was created, but the graph endpoint the sensor waits for is not reachable.

## Same machine on 7.1.8 — works

```
intel-ipu7 0000:00:05.0: Connected 1 cameras
ov08x40 i2c-OVTI08F4:00: supply dovdd not found, using dummy regulator
intel_ipu7_isys.isys intel_ipu7.isys.40: bind ov08x40 17-0036 nlanes is 2 port is 0
intel_ipu7_isys.isys intel_ipu7.isys.40: All sensor registration completed.
```

`entity 233: ov08x40 17-0036 (1 pad, 1 link)`, `/dev/v4l-subdev4`, camera streams normally. Nothing about the userspace, the ACPI tables or the hardware changed between the two boots — only the kernel.

## Data point: the in-tree staging driver gets further

Uninstalling the DKMS modules for that kernel (`dkms uninstall ipu7-drivers/1.0.5 -k 7.2.3-arch1-1-ptl`, which restores the archived in-tree `intel-ipu7.ko` / `intel-ipu7-isys.ko`) changes the picture:

- `ov08x40` **binds**, and the deferred-probe entry is **gone** — so the in-tree `ipu-bridge` does produce a usable endpoint for this sensor on 7.2.3
- ISYS still does not add the sensor to the media graph, and libcamera 0.7.2 reports `SimplePipeline: No sensor found for /dev/media0`, so this is not a complete workaround

A possibly relevant difference: the in-tree `ipu-bridge` carries `OVTI08F4` in its supported-sensor table

```
$ strings .../ipu-bridge.ko | grep -E '^(OVTI|HIMX)[0-9A-Z]{4}$' | sort -u | tr '\n' ' '
HIMX11B1 HIMX2170 HIMX2172 OVTI01A0 OVTI01AS OVTI02C1 OVTI02E1 OVTI05C1 OVTI08A1 OVTI08F4 OVTI13B1 OVTI2680 OVTI5675 OVTI8856 OVTIDB10
```

whereas the DKMS `ipu-acpi.ko` contains no `OVTI08F4` string at all (0 matches) and appears to rely purely on generic SSDB parsing.

## Reproduction

1. Panther Lake laptop with OV08X40 behind SVP7500, ipu7-drivers 1.0.5 via DKMS
2. Boot any 7.1.x kernel → camera works
3. Boot 7.2.x, same userspace and same DKMS source → `cat /sys/kernel/debug/devices_deferred` shows `ov08x40: waiting for fwnode graph endpoint`, no sensor entity in `/dev/media0`

## Relation to existing issues

- **#79** (Lunar Lake, OV02C10, kernel 7.0.12) analyses bridge-created software nodes not being reachable from the ISYS fwnode traversal. Very likely the same underlying fragility, but that report is ISYS-side (`no subdevice info provided`) and on a different platform/kernel; mine is sensor-side and has a sharp 7.1 → 7.2 boundary.
- **#63** is the same machine class (Panther Lake, OV08X40, SVP7500) but concerns PSYS deferring on `ipu7_bus_ready_to_probe`, not the sensor.
- **#93** concerns the `struct ipu7_bus_device` ABI break when mixing DKMS psys with in-kernel `intel_ipu7`.

Note: this machine also hit an unrelated userspace breakage at the same time — a `jsoncpp` soname bump
that stops Intel's HAL plugin from loading (tracked at omacom/omarchy#10837). That one is fixed here and
is not the cause of the sensor problem above: with the HAL working, the sensor still never binds on 7.2.x,
and on 7.1.8 it binds regardless.

Happy to test patches, collect additional traces (dynamic debug on `intel_ipu7_isys` produced no output here), or dump the ACPI SSDB/`_DSD` data for this sensor if that helps.

Start by comparing the DKMS ipu-acpi and in-tree ipu-bridge behavior across the working 7.1.8 and failing 7.2.3 kernels. Inspect the ov08x40 deferred-probe message, the created software_node, and intel_ipu7_isys registration path; use the reported debugfs, media-ctl output, and available ACPI SSDB/_DSD data. Done means the sensor binds and appears in the ISYS media graph on 7.2.x.

Written by the indexing model from the issue text.