cardano-node crashes with STATUS_FATAL_USER_CALLBACK_EXCEPTION (0xc000041d) on Windows, leaving ChainDB dirty

## Description

cardano-node hard-crashes on Windows with exception code `0xc000041d` (`STATUS_FATAL_USER_CALLBACK_EXCEPTION`). The process terminates without any shutdown logging, leaving the ChainDB in a dirty state. On the next startup, the node triggers a full ImmDB validation of all ~8,981 chunks (~2–3 hours), during which the wallet API is unavailable and Daedalus appears permanently disconnected.

## Environment

- **OS**: Windows 10.0.19045
- **cardano-node version**: 11.0.1-97036a66b
- **cardano-wallet version**: 2026.5.11-c642e0779
- **Daedalus version**: 11.0.0 (build 50706edb8)
- **Network**: Mainnet
- **CPU**: 12th Gen Intel Core i9-12900KF
- **RAM**: 63.8 GB

## Steps to Reproduce

1. Run Daedalus/cardano-node on Windows for an extended period while fully synced
2. Node crashes (no user action required — appears to occur spontaneously)

## Observed Behaviour

- cardano-node process (PID 2520) terminates abruptly with no shutdown log entries
- Windows Application Error Event Log records:
- **Event ID**: 1000
- **Time**: 2026-08-01T21:09:57Z
- **Faulting process ID**: `0x9d8` (2520)
- **Exception code**: `0xc000041d` (`STATUS_FATAL_USER_CALLBACK_EXCEPTION`)
- **Faulting module**: `bad_module_info` / `unknown` (Windows cannot identify the GHC RTS module)
- On restart, node logs: `ChainDB is not clean. Validating all immutable chunks`
- Full validation of 8,981 chunks proceeds at ~1 chunk/sec (~2.5 hours total)
- Daedalus shows disconnected / not syncing for the entire validation period

## Expected Behaviour

- cardano-node should handle the exception and shut down cleanly, or
- At minimum, write a shutdown reason to the log before terminating

## Additional Context

The crash occurred after the node had been running for several hours in a quiet/stable state (fully synced, stable peers). The last log entry before the crash was at 17:05:43Z, with the crash confirmed at 21:09:57Z — a ~4 hour gap with no log output, suggesting the node was running but idle.

The `bad_module_info` / `unknown` faulting module is typical for GHC-compiled executables on Windows, as the GHC RTS uses custom memory management that Windows error reporting cannot introspect. A minidump or WER report would be needed for a full stack trace.

The `STATUS_FATAL_USER_CALLBACK_EXCEPTION` code typically indicates an unhandled exception inside a Windows kernel callback or APC — potentially caused by heap or stack corruption in the GHC RTS.

### Relevant node.log excerpt (startup after crash)

```
[2026-08-01 21:10:40.2513Z][ChainDB.LastShutdownUnclean] ChainDB is not clean. Validating all immutable chunks
[2026-08-01 21:10:40.2513Z][ChainDB.OpenEvent.StartedOpeningDB] Started opening Chain DB
[2026-08-01 21:10:40.2513Z][ChainDB.OpenEvent.StartedOpeningImmutableDB] Started opening Immutable DB
[2026-08-01 21:10:40.4013Z][ChainDB.ImmDbEvent.ChunkValidation.StartedValidatingChunk] Validating chunk no. 0 out of 8981. Progress: 0.00%
```

Validation was still in progress at 28.23% (chunk 2535/8981) when Daedalus was closed ~15 minutes later.

### Windows Event Log entry

```xml

1000

MASKED


bad_module_info
0.0.0.0
unknown
c000041d
00007ffbc143c380
9d8

```

No source file, test, or code entry point is identified in the report. Start by reproducing the Windows crash while collecting a minidump or WER report and correlating it with node.log and the Windows Application Error entry; completion would require an identified failure cause and a testable clean-shutdown or diagnostic-logging fix.

Written by the indexing model from the issue text.