DF-4486 — stale per-output notify handler after REPROBE destroy

Root cause (code-certain, no runtime claim): - sys/dev/acpica/acpi_video/acpi_video.c:385-395 — the VID_NOTIFY_REPROBE (0x81) handler NULLs vo->handle for every output, rebinds those matched by the namespace walk, and destroys the unmatched ones. - sys/dev/acpica/acpi_video/acpi_video.c:627-631 — acpi_video_vo_destroy() removes the per-output notify handler via AcpiRemoveNotifyHandler(vo->handle, ACPI_DEVICE_NOTIFY, ...). For an unmatched output vo->handle is NULL at this point. - sys/contrib/dev/acpica/source/components/events/evxface.c:399-402 — AcpiRemoveNotifyHandler() returns AE_BAD_PARAMETER for a NULL Device and does nothing. The return value is ignored by the caller. - Result: the handler installed at first bind (acpi_video.c:611-613, AcpiInstallNotifyHandler(handle, ACPI_DEVICE_NOTIFY, acpi_video_vo_notify_handler, vo)) stays registered on the REAL (old) device node with context = vo, and kfree(vo, M_ACPIVIDEO) then runs (acpi_video.c:654). Any later firmware notify delivered on that node runs acpi_video_vo_notify_handler() with a freed vo: - :679 if (vo->handle != handle) — UAF read of freed memory; - :684-737 on brightness notifies — reads vo->vo_numlevels / vo->vo_levels[i] from freed memory and WRITES vo->vo_brightness = new_level (:737) into the freed chunk (4-byte write-after-free, value limited to a listed level 0..100). - Additionally acpi_video_vo_bind() (:594-615) never removes the old handler before installing on the rebind handle; ACPICA rejects the second install with AE_ALREADY_EXISTS (evxface.c:309-311) so the stale registration survives even a successful rebind when the handle is unchanged.

Why "untested" (not runtime-verified): making the stale-handler dispatch visible requires reallocating the freed M_ACPIVIDEO chunk with controlled content (so vo->handle == handle passes) — M_ACPIVIDEO is only allocated by this driver's acpi_video_vo_init(), so an in-guest demonstration would need a second controllable allocation of that exact malloc type, which the driver does not offer. The destroy-with-NULL-handle path itself is proven reachable on the guest (DF-4484's REPROBE choreography destroys unmatched outputs the same way; the panic trace in DF-4484/panic.txt shows vo_destroy running on that path).

Fix: part of DF-4484's fix.diff — track reprobe matching with a vo_matched flag instead of NULLing vo->handle (so vo_destroy always removes the handler from the real node), and remove the old handler in vo_bind before re-install.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.

(No fix.diff for this item: documented recommendation only - see Fix above.)