feat(recovery): opt-in deep USB recovery rung below the port reset

[andrescera]

What

Adds one opt-in escalation below the existing USB port reset, for the case the
reset itself cannot fix: a reset the device never comes back from.

New property deep-port-recovery (boolean, default false). When
enabled, and only after the port reset and every reopen inside
reset-settle-max-ms have already failed, the element escalates once:

1. device-level authorized 0→1 — if the device object survived and still
   reports the vid:pid captured before the reset;
2. port-level disable 1→0 (1 s hold) — if the device object is gone.

Then one further settle pass, which still requires a delivered frame, before
falling through to the usual RESOURCE/READ disconnect error.

The mechanism lives in a new standalone helper (usb_port_recovery.{c,h}) with
no GObject, libuvc or libusb dependency and a parameterised sysfs root, so the
same rung can be driven from outside this element later without reimplementing
a privileged mechanic.

Why

Two recorded incidents left a camera at error -71 after USBDEVFS_RESET
cycling, needing a physical replug. In that state the kernel has exhausted
PORT_INIT_TRIES, logged unable to enumerate USB device, and created no
usb_device — so there is nothing for another libusb_reset_device() to reset,
and the element could only report a disconnect.

The originally-specified attribute was wrong. Measured on the board across
14 ports and 12 devices: authorized exists only on DEVICE directories,
disable only on PORT directories, and neither object carries the other's. A
device that failed enumeration has no device directory at all — which is why the
port path is resolved from the device's port symlink before the reset
rather than derived afterwards.

Why it defaults to false — this is a measured decision, not caution. A
live error -71 device was present on the board and the rung was driven against
it three times. The port cycle executes exactly as designed: PORTSC goes
Powered Connected Enabled → Powered-off Not-connected Disabled and returns
with a genuine connect-status-change, and the kernel re-runs enumeration with a
fresh address. The device did not come back, 0/3. The kernel had already
been doing the same power cycle on every one of its own retries
(usb usb9-port1: attempt power cycle) to no effect. Enabling this by default
would spend a second settle budget and root-only sysfs writes on every wedge
with no evidence behind it.

No VBUS claim is made. The hub control-transfer round-trip answers
wHubCharacteristic 0x000a — "No power switching" — corroborated by
HCCPARAMS1 = 0x0220fe64 (PPC = 0), while PORTSC still toggles. The
capability bit is unreliable here and the board's Type-C rail is a separate GPIO
regulator, so the code, logs and docs all call this a logical port-state
cycle.

How to verify

cmake -B build && cmake --build build && ctest --test-dir build --output-on-failure
cmake -B build-san -DENABLE_SANITIZERS=ON && cmake --build build-san \
  && ctest --test-dir build-san --output-on-failure

• 135/135 plain, 190/190 with ASan+TSan.
• 16 new cases: 9 helper (synthetic sysfs tree), 6 ladder-ordering, 1 API guard.
• Red-first: neutralise the escalation call and the ordering cases fail 3/6
  with the deep rung must fire once …, got 0. The two that pass in both states
  are negative controls that assert the rung does not run.
• Property surface: gst-inspect-1.0 libuvch264src | grep deep-port-recovery
  shows Boolean. Default: false.

Risks

• Roughly doubles worst-case recovery time when enabled (a second full
  reset-settle-max-ms), plus a 1 s hold and a disable write that was measured
  blocking ≈2.5 s on the hub device lock. Mitigated by being opt-in and off.
• Needs root. cerastream.service has no User=, so an embedded element can
  write; a hand-run gst-launch gets EACCES and the rung reports denied rather
  than appearing to have tried.
• Could disturb an unrelated device — addressed by two vetoes, both from
  measured hardware: it refuses any port whose hub carries another enumerated
  device (ganged hubs are real here — the board's Terminus 1a40:0101 reports
  Ganged power switching), and refuses a device whose vid:pid no longer matches,
  since bus addresses are recycled.
• Existing behaviour is untouched. A failed reset (LIBUSB_ERROR_NO_DEVICE)
  still returns immediately without escalating, so
  absent_device_reset_fails_through and its exact open-count assertion still
  hold. No test was deleted, skipped or weakened.

Board evidence SHA256:
918d9ab328bb01f0151ebdffdbc6d8e88943e023f07ae74c1459506ddb9361d3