[BUG] esp32 pid controller + psram issue

### Description / Steps to reproduce the issue

see the following test code:

```c
#include

void print_stackinfo(const char *label, const struct stackinfo_s *p) {
printf("%s: %p: %zu %p %p\n", label, p, p->adj_stack_size, p->stack_alloc_ptr,
p->stack_base_ptr);
}

void test(void) {
int i;

struct stackinfo_s s;
nxsched_get_stackinfo(0, &s);
for (i = 0; i < 4; i++) {
print_stackinfo("iram", &s);
}

struct stackinfo_s *psram = (void *)SOC_EXTRAM_DATA_LOW;
nxsched_get_stackinfo(0, psram);
for (i = 0;; i++) {
print_stackinfo("psram", psram);
if (psram->stack_alloc_ptr == s.stack_alloc_ptr) {
break;
}
}
}
```

run it with a configuration where:
* esp32 protected mode
* userland pid is 5 (ie. CONFIG_ESP32_USER_DATA_EXTMEM is not set)
* psram is initialized but not registered to any nuttx system heaps. (so that user apps can use them directly)

for some reasons, it prints garbage-looking values on the first run as the following.

```shell
nsh> esp32_pid
print_stackinfo(iram): 0x3ffca290: 2000 0x3ffc9b40 0x3ffc9b70
print_stackinfo(iram): 0x3ffca290: 2000 0x3ffc9b40 0x3ffc9b70
print_stackinfo(iram): 0x3ffca290: 2000 0x3ffc9b40 0x3ffc9b70
print_stackinfo(iram): 0x3ffca290: 2000 0x3ffc9b40 0x3ffc9b70
print_stackinfo(psram): 0x3f800000: 1145050453 0x5d755d51 0x3ffd9b54
print_stackinfo(psram): 0x3f800000: 1145050453 0x5d755d51 0x3ffd9b54
print_stackinfo(psram): 0x3f800000: 1145050453 0x5d755d51 0x3ffd9b54
print_stackinfo(psram): 0x3f800000: 1145050453 0x5d755d51 0x3ffd9b54
nsh> esp32_pid
print_stackinfo(iram): 0x3ffca290: 2000 0x3ffc9b40 0x3ffc9b70
print_stackinfo(iram): 0x3ffca290: 2000 0x3ffc9b40 0x3ffc9b70
print_stackinfo(iram): 0x3ffca290: 2000 0x3ffc9b40 0x3ffc9b70
print_stackinfo(iram): 0x3ffca290: 2000 0x3ffc9b40 0x3ffc9b70
print_stackinfo(psram): 0x3f800000: 2000 0x3ffc9b40 0x3ffc9b70
nsh> esp32_pid
print_stackinfo(iram): 0x3ffca290: 2000 0x3ffc9b40 0x3ffc9b70
print_stackinfo(iram): 0x3ffca290: 2000 0x3ffc9b40 0x3ffc9b70
print_stackinfo(iram): 0x3ffca290: 2000 0x3ffc9b40 0x3ffc9b70
print_stackinfo(iram): 0x3ffca290: 2000 0x3ffc9b40 0x3ffc9b70
print_stackinfo(psram): 0x3f800000: 2000 0x3ffc9b40 0x3ffc9b70
nsh>
```

my understanding is that
1. nxsched_get_stackinfo system call (the kernel, which runs with pid 0) wrote the values to the buffer (psram)
2. the thread returned to the userspace. (thus switch its pid back to 5)
3. the userspace read the buffer immediately and got the wrong values for some reasons
4. for some reasons, after a while (5th iteration of the loop in the following example), it started reading the correct values.

maybe pid controller takes longer to get ready than usual?

i suspect this can explain the problem which forced us to use pid 1 for CONFIG_ESP32_USER_DATA_EXTMEM in the first place.
i wonder if there is a reasonable way to wait for the pid controller (or maybe mmu/cache? i dunno) ready after a pid switch.

### On which OS does this issue occur?

[OS: Mac]

### What is the version of your OS?

macos

### NuttX Version

modified master

### Issue Architecture

[Arch: xtensa]

### Issue Area

[Area: Specific Peripheral]

### Verification

- [X] I have verified before submitting the report.

Start with the provided C test using nxsched_get_stackinfo under ESP32 protected mode, userland PID 5, and unregistered PSRAM, then reproduce the differing first-run and later output. Investigate the PID switch and PSRAM access path described in the report. Done means identifying the cause of the stale or incorrect stackinfo values and establishing a reliable fix or documented synchronization requirement.

Written by the indexing model from the issue text.