Out-of-tree ISYS driver fails to discover sensors on kernel 7.0.x (Lunar Lake / IPU7): ipu_bridge INT343E software node not reachable from ISYS fwnode graph

## System

- **Hardware**: Dell XPS, Intel Core Ultra 7 258V (Lunar Lake)
- **Sensor**: OmniVision OV02C10 (ACPI ID: `OVTI02C1`) on I2C bus 16, address 0x36, 2 MIPI lanes
- **Kernel**: 7.0.12-201.fc44.x86_64 (Fedora 44)
- **ipu7-drivers**: latest main branch (PACKAGE_VERSION=0.0.0)
- **ipu_bridge**: in-kernel (from kernel 7.0.12 staging)

## Setup

Since kernel 7.0.x includes `intel-ipu7.ko` and `intel-ipu7-isys.ko` in staging, the DKMS config only builds `intel-ipu7-psys`. However, the out-of-tree psys module hangs indefinitely during probe when binding to the auxiliary device created by the in-kernel `intel-ipu7.ko` (stuck in `pm_runtime_resume_and_get`), indicating an ABI mismatch between the in-kernel and out-of-tree versions.

**Workaround attempted**: Force-build all three modules (intel-ipu7, intel-ipu7-isys, intel-ipu7-psys) from ipu7-drivers by removing the kernel version check in the Makefile/dkms.conf. This makes psys probe successfully and `/dev/ipu7-psys0` appears.

## Problem

With the full out-of-tree stack loaded, the ISYS driver logs:

```
intel_ipu7_isys.isys intel_ipu7.isys.40: no subdevice info provided
```

And the sensor never binds — `media-ctl -p` shows no OV02C10 entity, and `gst-launch-1.0 icamerasrc ...` reports `No sensors available`.

## Root Cause

`ipu_bridge_init()` (called from `ipu7_isys_init()` in `ipu7.c`) creates a software node named `INT343E` with the sensor graph endpoints:

```
/sys/kernel/software_nodes/INT343E/port@0/endpoint@0
/sys/kernel/software_nodes/OVTI02C1-0/port@0/endpoint@0
```

However, this `INT343E` software node is **not attached** to the IPU7 PCI device (`0000:00:05.0`, ACPI path `\_SB_.PC00.IPU0`) as a secondary fwnode. On Lunar Lake there is no `INT343E` ACPI device — the IPU is exposed directly on the PCI bus.

As a result, `isys_notifier_init()` in `ipu7-isys.c` calls:

```c
ep = fwnode_graph_get_endpoint_by_id(dev_fwnode(dev), i, 0,
FWNODE_GRAPH_ENDPOINT_NEXT);
```

This searches `dev_fwnode(&isp->pdev->dev)` which is the ACPI fwnode for `\_SB_.PC00.IPU0` — it has no graph endpoints, so no sensors are found and the notifier's waiting list stays empty.

The in-kernel staging `intel-ipu7-isys.ko` does not have this problem (sensor binds correctly at boot), suggesting the in-kernel version handles this differently.

## Kernel log (boot with out-of-tree full stack)

```
intel-ipu7 0000:00:05.0: Found supported sensor OVTI02C1:00 ← bridge works
intel-ipu7 0000:00:05.0: Connected 1 cameras
ov02c10 i2c-OVTI02C1:00: supply dovdd not found, using dummy regulator
intel_ipu7_isys.isys intel_ipu7.isys.40: no subdevice info provided ← spdata NULL (expected)
← no sensor bind
```

## Expected behavior

- `isys_notifier_init()` should find the sensor endpoints created by `ipu_bridge` and register the async notifier
- `ov02c10` should bind to the ISYS
- `/dev/video*` should show a working camera pipeline

## Questions for maintainers

1. How does the in-kernel staging `intel-ipu7-isys.ko` (kernel 7.0.12) discover sensors — does it use a different fwnode traversal or a different code path?
2. Should `ipu7_isys_init()` in `ipu7.c` call `set_secondary_fwnode(dev, software_node_fwnode(swnode))` after `ipu_bridge_init()` to attach the INT343E node to the PCI device?
3. Should `isys_notifier_init()` in `ipu7-isys.c` fall back to `software_node_find_by_name(NULL, IPU_HID)` when `dev_fwnode(dev)` has no graph endpoints?
4. Is the psys probe hang with the in-kernel `intel-ipu7.ko` (kernel 7.0.x) a known issue? Is using the full out-of-tree stack the intended path on these kernels?