solo-erase flakes in full-suite runs: the erased device's IndexedDB database survives the erase

[lannbot]

Observed on the merged tree of #108 + #109 (neither alone had shown it):

• main run 32816934522, first attempt: FAIL solo-erase — pm-device-<id> (the database) survived the erase: expected false, got true (33/34). The rerun of the same commit passed 34/34.
• One local full-suite run of the same tree failed 33/34 (scenario identity not captured); the immediate local rerun passed 34/34.
• solo-erase ALONE passes 6/6 locally — the flake needs suite context (load, ordering, or a prior scenario's residue).

Shape: the erase ceremony completed (no onblocked rejection — that would have failed the ceremony act itself), the page reloaded onto the first-run fork correctly, and yet the device's IndexedDB database EXISTS again at the post-reload check. That reads as resurrection, not survival: something re-created pm-device-<id> after the destroy — a worker outliving the reload window with an armed timer (checkpoint debounce, flush debounce) whose firing re-opens the namespace and re-creates the database as a side effect of open-on-missing.

Candidate wideners, in suspicion order:

• Recovery: the account outlives its last device #109 added explicit post-internal-mutation checkpoints (consume/kit-create/kit-revoke) and put the us-doc on the flush cycle — more armed timers and more late async in the worker's tail than before (though none of the kit paths run in solo-erase's story, the scheduler changes are global).
• Testing the browser partial-availability edges: faults the harness can now inject, heals it now demands, and gaps it now pins #108 added CDP-level fault machinery and heavier scenarios ahead of solo-erase in the order — more load and more browser-target churn at exactly the point the suite reaches it.
• The race may be pre-existing (destroy vs a debounced checkpoint has no obvious cancellation handshake) and merely newly visible at the merged suite's length.

Reproduction lever to try first: run the suite from solo-storage onward in a loop, or artificially arm the checkpoint debounce just before the erase ceremony and assert the database stays gone across the window. The fix direction, if the hypothesis holds: destroy must cancel/await every armed timer and in-flight internal driver call before dropping the namespace, and open-on-missing paths in sealed-fs/idb should refuse to re-create a namespace whose index row is gone.