bhyve: Keep the xhci event ring's fill count right when it is nearly full

[wanpengqian_gmail.com]

Summary

With er_events_cnt == er_size - 1, pci_xhci_insert_event() decided
whether the ring is full from the cycle bit of the TRB at the enqueue
slot. That TRB is from the previous lap (or zero on the first one), so
its cycle bit never matches the producer's and the event went into the
last free slot without being counted: the count then said one less than
the ring held, and the next event overwrote a TRB the guest had not
consumed yet. When the Event Ring Full Error was written at the end of
the segment, the producer cycle state was not toggled either.

Follow xHCI 4.9.4: keep one slot for the Event Ring Full Error, post it
there when the ring is otherwise full, and toggle the cycle state on a
wrap as for any other event.

Together with the unlocked hci_intr path (D60432) this showed up as
Windows 10 stopping the tablet's endpoint and resetting the controller
under fast mouse input over VNC/RDP.

Signed-off-by: Wanpeng Qian <[e-mail]>
Sponsored by: keelos.dev

Test Plan

Built with and without WITH_BHYVE_SNAPSHOT (no new warnings).

The same change has been in keelOS's bhyve since 2026-10-07, together with the hci_intr locking of D60432, where Windows 10/11, macOS and Linux guests drive the tablet and keyboard through this model over VNC/RDP: the endpoint-stop/HCRST loop Windows 10 went into under fast mouse input (tablet reports arriving faster than the guest drains the 256-entry event ring) does not recur there. With the controller's trace in that build, when the ring does fill the guest sees one Event Ring Full Error TRB, consumes it, and the ring carries on with the right cycle state after the wrap.