SOC task hangs while processing USB_EVT_READY

### Operating System

MacOS

### Arduino IDE version

IDE 2.3.4, CLI 1.1.1

### Board

Derivative of feather_nrf52840_express (using #define USE_LFRC)

### ArduinoCore version

derivative of adafruit:nrf52@1.3.0

### TinyUSB Library version

e58ed11de15e2cfbd71f1a79cf84a2372ba27e08

### Sketch as ATTACHED TXT

I do not have a sketch that will reliably reproduce the issue, but see the 'How to reproduce' section for relevant excerpts from our sketch.

### Compiled Log as ATTACHED TXT

no log available

### What happened ?

We observed a spurious task hang in the TinyUSB code. The SOC task in [Adafruit_nRF52_Arduino](https://github.com/adafruit/Adafruit_nRF52_Arduino) was hung not allowing the idle task to run and finally causing a watchdog reset on our system when the idle task could no longer service the watchdog. When analyzing the PC at the time of the watchdog, it pointed to a hang on line 1006 of dcd_nrf5x.c:

```c
case USB_EVT_READY:
// Skip if pull-up is enabled and HCLK is already running.
// Application probably call this more than necessary.
if ( NRF_USBD->USBPULLUP && hfclk_running() ) break;

// Waiting for USBD peripheral enabled
---> while ( !(USBD_EVENTCAUSE_READY_Msk & NRF_USBD->EVENTCAUSE) ) { }

NRF_USBD->EVENTCAUSE = USBD_EVENTCAUSE_READY_Msk;
__ISB(); __DSB(); // for sync
```

The watchdog triggered 3320409ms (just shy of an hour of uptime, similar to the issue: hathach/tinyusb#2882). The hang would have occurred approximately 60 seconds prior to this reboot.

Please note that we are opening this issue as an advisory; we do not view this issue as a critical showstopper to using this library. We have run this code for quite some time (several years, on many different devices we have been experimenting with). This is the ONLY time we have seen it during that time.

@hathach Feel free to close this issue, it is only meant to callout that there may be an issue with waiting indefinitely for the ready bit in NRF_USBD->EVENTCAUSE after receiving the USB_EVT_READY from nrfx.

### How to reproduce ?

The issue was triggered in an idle state with VBUS connected at 4.65-4.7 volts. D+ and D- on the nRF52840 were NOT connected anytime during the hour uptime for the device. We have seen this issue only ONCE in the last 3 years and we do not have a sketch that can reliably reproduce this issue.

We did have a number of tasks running at the time, however they were all lightly loaded, collecting data from sensors every couple of seconds then sleeping again. The onboard Accelerometer would have been driving regular interrupts (about once a second) during that time, but still lightly loaded.

```
Task State Prio StackLeft Num
-----------------------------------
loop X 1 572 1
IDLE R 0 26 3
CLI B 1 963 12
Persist B 1 997 11
Collect B 1 990 10
Callbac B 2 729 2
SOC B 3 163 7
BLE B 3 1195 6
Accel D S 3 997 8
Audio E S 1 828 9
usbd B 3 132 5
Tmr Svc B 2 217 4
```

TinyUSB is invoked in the most generic way possible and we are only using it for USB Serial (i.e. NO MSC, HID, etc...)

```c
#include
#include // for Serial
#include

...

void setup()
{
...

Bluefruit.begin();

...

// For debugging via serial console
if(!Serial) Serial.begin(115200);
delay(10);

...
}

void loop()
{
// Wait for a periodic poke to evaluate the state machine
uint32_t val = ulTaskNotifyTake( pdTRUE, pdMS_TO_TICKS( 5000 ));

// Update BLE characteristic unixTime
updateUnixTime();

// Run the statemachine
FSM_sttKernel(&coreStt);
}
```

### Debug Log as ATTACHED TXT

_No response_

### Screenshots

_No response_

### I have checked existing issues, pr, discussion and documentation

- [x] I confirm I have checked existing issues, pr, discussion and documentation.

Start at dcd_nrf5x.c around line 1006, in the USB_EVT_READY handler, and review the indefinite wait on NRF_USBD->EVENTCAUSE after nrfx signals readiness. Use the reported nRF52840 setup and idle-state conditions as context; done requires determining whether the wait can hang and documenting or addressing the safe behavior, though the report provides no reliable reproducer or test file.

Written by the indexing model from the issue text.