Fix Session Host startup logging after WinRT shutdown

[yiguodev]

Problem

An unpackaged Session Host should refuse startup safely, but it exits with 0xC0000005 instead. run() first gets a normal no-package error from ApplicationData::Current(), then drops its WinRT guard. The executable subsequently calls startup logging, which queries the cached factory after RoUninitialize.

A minimal Windows probe reproduced the access violation on that second query. Dropping the original error after uninitialization did not crash; reinitializing before reusing the cached factory did not fix the problem.

Change

Keep startup and best-effort failure logging inside the same WinRT initialization lifetime. Make the logging helper private, and add a bounded process-level regression test that refuses to run with package identity. There is no fallback storage location, new activation path, exit-code whitelist, or protocol/ABI revision change.

Validation

• The regression failed with 0xC0000005 before the change and passed afterward.
• ARM64 and x64 Release regression tests passed on Windows 11 ARM64; x64 execution was emulated.
• cargo test --locked --target aarch64-pc-windows-msvc --all-features --all-targets: 486 passed, 5 intentionally ignored.
• Clippy (--all-features --lib --bins -- -D warnings), formatting, C-header/TLS checks, and all 8 script tests passed.
• The normal ARM64 artifact build passed its architecture and build-identity checks.

The expanded full Release test run uncovered an independent existing failure in ffi::tests::runtime_thread_cannot_reenter_invoke; it was also reproduced on unchanged base fb1b53f. RuntimeThreadGuard currently puts its state mutation inside debug_assert!, so release builds omit it. This PR deliberately does not modify that separate FFI boundary.

No packaged activation, live VPN, Windows 10, or native x64 acceptance is claimed.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.