3.1.2: Possible regression with WiFi-connection after ESP.deepSleep( , RF_DISABLED)

Disclaimer: AI written report with edits after troubleshooting with AI assistance

### Description

After waking from `ESP.deepSleep()` using `RF_DISABLED` and connecting to WiFi, the following debug message appears consistently on every single wake cycle: `error: pll_cal exceeds 2ms!!!`

Despite this message, the WiFi connection still succeeds and the sketch continues to run as expected (at least over a few minutes). The message appears immediately after the boot log, before any of my sketch's own `Serial.println()` output. This occurs 100% reproducibly, every single deep sleep cycle, not intermittently.

### Basic Infos

- Hardware: NodeMCU (Lolin V3 clone / AZ-Delivery), ESP-12F module
- Core Version: 3.1.2 (issue present) / 3.1.1 (issue absent — confirmed fix by downgrade)
- Development Env: Arduino IDE 2.3.10
- Operating System: Linux 7.1.9-200.fc44.x86_64
- Probably unrelated issue, but for completeness sake: This particular board/batch freezes after deep sleep without an added resistor between S0 and 3V3

### Settings in IDE

- Module: NodeMCU 1.0 (ESP-12E Module)
- Flash Size: 4MB (FS:2MB OTA:~1019KB )
- CPU Frequency: 80MHz
- lwIP Variant: v2 Lower Memory
- Upload Using: Serial

**Troubleshooting:**
- Tested with two different USB cables on different USB ports to rule out power supply issue as best as I can.
- Added `WiFi.disconnect()` before `ESP.deepSleep()`.
- Tested with `delay(1)` and `delay(1000)` at the very start of `setup()`, before any WiFi calls.

**Found fixes:**
**A:** Downgrading the "esp8266 by ESP8266 Community" boards package from **3.1.2 to 3.1.1** resolved the issue completely on identical hardware and sketch. This makes a regression between 3.1.1 and 3.1.2 likely.

**B:** Changing the wake mode parameter from
`ESP.deepSleep(sleepTimer * 1000000ULL, RF_DISABLED);`
to
`ESP.deepSleep(sleepTimer * 1000000ULL, RF_NO_CAL);`
also produces a clean boot with no `pll_cal` error on core 3.1.2, without downgrading.

This suggests the regression might be related to how RF calibration is triggered on-demand (by `WiFi.begin()`) when waking with `RF_DISABLED`, rather than a general boot-time RF_CAL issue — since skipping calibration entirely via `RF_NO_CAL` avoids it too. Something appears to have changed between 3.1.1 and 3.1.2 in how/when RF calibration is invoked when the radio was left disabled on wake.

### Sketch
(also tested and reproduced with WiFiShutdown example)

```cpp
#include
#include
#include

const int sleepTimer = 5;

const char *ssid = "";
const char *password = "";

WiFiUDP ntpUDP;
NTPClient timeClient(ntpUDP, "pool.ntp.org");

void setup() {
delay(1);

pinMode(2, OUTPUT);
digitalWrite(2, LOW);

Serial.begin(74880);
while (!Serial);
Serial.println("\nI'm alive!");

WiFi.mode(WIFI_STA);
Serial.print("\nConnecting to ");
Serial.println(ssid);
WiFi.begin(ssid, password);
while (WiFi.status() != WL_CONNECTED) {
delay(500);
Serial.print(".");
}

timeClient.begin();
timeClient.setTimeOffset(0);
timeClient.update();
String formattedTime = timeClient.getFormattedTime();
Serial.print("\nTimestamp: ");
Serial.println(formattedTime);

WiFi.disconnect();
delay(10);
Serial.println("\nGoing back to sleep ...");
Serial.flush();
ESP.deepSleep(sleepTimer * 1000000ULL, RF_DISABLED);
}

void loop() {}
```

### Serial Monitor

**With core 3.1.2, RF_DISABLED (broken):**
ets Jan 8 2013,rst cause:2, boot mode:(3,7)

load 0x4010f000, len 3424, room 16
tail 0
chksum 0x2e
load 0x3fff20b8, len 40, room 8
tail 0
chksum 0x2b
csum 0x2b
v00043e20
~ld
error: pll_cal exceeds 2ms!!!
rf cal sector: 1020
freq trace enable 0
rf[112] : 0�
I'm alive!

Connecting to WLAN
...........
Timestamp: 10:46:19

Going back to sleep ...

**With core 3.1.2, RF_NO_CAL (working) / with core 3.1.1, RF_DISABLED (working):**
ets Jan 8 2013,rst cause:2, boot mode:(3,7)

load 0x4010f000, len 3424, room 16
tail 0
chksum 0x2e
load 0x3fff20b8, len 40, room 8
tail 0
chksum 0x2b
csum 0x2b
v00043da0
~ld

I'm alive!

Connecting to WLAN
..........
Timestamp: 10:44:06

Going back to sleep ...