#3488 [GUI] Stuck after an interrupted load: a dead engine PID blocks it, then the integrity check fails on intact files

Description

## Bug 1 — a dead engine PID blocks every load

After a load is interrupted (the app is closed during "Starting…", or the model is stopped), every later load fails at once:

    lost host child is still present; retry after it exits

"Stop" and "Load" do not clear it; the engine never starts.

`strata_control/runtime.py`, `_recover_stale()` reads the marker `…\Local\Strata\runtime\app-1-<token>.child.json`, waits up to 45 s for its PID and refuses while that PID exists:

    {"host_token": "…", "phase": "owned", "pid": 38552, "ready": "…ready.json"}

That PID was already gone — `tasklist /fi "pid eq 38552"` finds nothing — so the marker was simply stale. It has no `started` field, so the creation-time check that is meant to tell a reused PID from the original cannot help either.

Suggested fix: in `_recover_stale()`, reclaim instead of raising when `_pid_exists()` is false; write `started` into the marker and treat a marker without it as stale; clean stale markers and `native-instances` entries at host start so a crashed load cannot leave the profile unable to load.

## Bug 2 — the engine is declared corrupt although every file matches

Right after the state above was cleared, the app showed:

    Strata did not recognise the engine for this computer…
    The engine package failed its integrity check, so it was not started:
    0.1.46 windows-x86_64-cuda: strata.exe does not match its recorded SHA-256

`/api/native` reported `engine.usable: false`, `version: null`. But the files are intact — every entry of `files[]` in `…\components\engine\0.1.46-windows-x86_64-cuda-cuda13\engine-component.json` matches sha256 and size, and so does the copy under `Programs\Strata\engine-bundle\…`:

    strata.exe        223 406 080  c2335807a15bc5f4…2c22
    BUILD.json              204  1c23400abc15db8d…97cff
    strata-vision.exe 108 206 592  6d169e297164728a…8907b
    strata_kq.dll      34 449 920  4eb789387ea1d692…882c
    cublas64_13.dll    51 776 624  b5846446f2a151ca…ea61
    cublasLt64_13.dll 478 140 016  680561bdc5d8a8c9…3ff1

`…\components\.updates\state.json` has an empty `engine` object, so no other expected hashes are stored. The engine log shows it actually started at 20:35:48 with the same arguments, and the next load succeeded (~47 tok/s at 11k prompt). Looks like the check ran against a file being unpacked or scanned, and the failure was then kept.

Suggested fix: verify against the manifest entry itself; if a file mismatches, print the expected and actual hash; retry the check once before refusing; do not cache the failure across restarts.

## Environment

Windows 10 19045, RTX 3090 24 GB, Strata 0.2.1, control 0.1.46.1, engine 0.1.46, qwen36-ud-q4_k_xl, context 262144, one GPU.

## Workaround that worked

Close the app, then (after a copy) remove `…\Local\Strata\runtime\app-1.json`, `app-1-*.child.json`, `app-1-*.ready.json` and the stale instance under `…\.strata\data\native-instances\`, delete non-finished entries from `…\.strata\data\native-jobs.json`, and start the app again. The next load passes; if the integrity notice appears once more, a second load starts the engine.