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.