Task watchdog gets triggered during Bluetooth initialization
SerialBT.begin(&quot;ESP32test&quot;) is hanging, and because ESP32 doesn't deal well with code that hangs, so it complains about it.
ESP32 runs a Real-Time OS (FreeRTOS).
The fact that it is a real-time OS means that execution of code needs to be guaranteed to finish within a certain time-frame. You'll often see RTOS functions containing the time limit in which that a blocking function should finish executing, such as:
    uart_wait_tx_done(uart_num, 100); // wait timeout is 100 RTOS ticks (TickType_t)

(from ESP-IDF docs)
FreeRTOS comes with a task API. Each task can execute code, but they need to give other tasks the chance to execute code too. I think that when a task blocks, it doesn't allow other tasks to do work on the same CPU. (but I can't find sources to back this up)
setup() runs in one of the RTOS tasks, and when SerialBT.begin() blocks the task for too long, the task watch dog complains that the task is hanging.
If the task is blocked by some kind of looping code, then it generally helps to run vTaskDelay() to yield the task to the task watchdog for a bit.
Because your task is blocked by a single call, there isn't much to do about it, given that SerialBT.begin() doesn't seem allow you to specify when it should time out.