Fix initialization order issue causing TLS access crash

[jinpzhanAMD]

Problem
Mimalloc v3.2.7 crashes during process initialization before any allocation is made. The crash occurs when using a 2-level page map configuration on 64-bit Windows.

Root Cause
The initialization sequence had an ordering bug:

mi_process_init() set _mi_process_is_initialized = true immediately after the once-guard check _mi_page_map_init() was then called to set up the page map.
During page map initialization, the call chain triggered: _mi_page_map_init() → _mi_os_alloc_aligned() → mi_os_prim_alloc_at() → mi_os_stat_counter_increase() → _mi_subproc() → _mi_theap_default()
_mi_theap_default() checked _mi_process_is_initialized and found it true
It then attempted to access TLS slots that hadn't been initialized yet → CRASH.
The fundamental issue: the process was marked as "initialized" before critical data structures were set up, and functions called during that setup trusted the flag and accessed uninitialized TLS data.

Solution
This PR implements a two-part fix:

1. Add early-exit guard in _mi_theap_default()
   This prevents premature TLS access by returning NULL when the process is not yet initialized.
   When _mi_theap_default() returns NULL during early initialization, _mi_subproc() safely falls back to _mi_subproc_main(), which is properly initialized as a static structure.

2. Move initialization flag assignment
   Move _mi_process_is_initialized = true to AFTER _mi_page_map_init() completes, ensuring the flag accurately reflects the actual initialization state.

[daanx]

Hi @jinpzhanAMD -- thank you for the detailed PR and root cause loop -- very useful and appreciated. I think this is fixed now by the commit for the other PR #1202; the crash in _mi_theap_default came about as the previous default slot was containing an arbitrary value (as it was TlsAlloc'd by some other module). Just for extra caution, I did move the _mi_process_initialized to a later moment.
The latest dev3 should work now -- let me know.