[7schmiede]

Refs #398. This PR captures the next hang so its cause can be found; it does not fix that cause.

• Watchdog (crates/devstack-hub/src/watchdog.rs):
  • A plain thread, outside the tokio runtime, sends GET /hub/ping to the hub's own port every 30 s and waits 10 s for an answer.
  • Only an HTTP status line counts as an answer. A connection the OS accepted on the hub's behalf does not, because a hub with a stuck runtime still accepts connections at the kernel until its queue is full. That is also why who_answers takes such a hub for foreign, and fix(hub): a start ends a hub that holds the lock and no longer answers (#398) #399's replacement never sees it.
  • After 2 minutes without an answer, the hub does the following, in order:
    1. writes hub-stuck-<ms>.dmp next to its log (Windows, MiniDumpWriteDump with thread info and indirectly referenced memory), keeping the newest 3 dumps
    2. logs hub_stuck with the path of the dump, or the error if writing it failed
    3. starts the next hub, which waits up to 15 s for the lock
    4. exits
• devstack_proc::write_dump: Windows only; elsewhere it answers Unsupported, and the hub still restarts.
• windows-sys: Win32_System_Diagnostics_Debug, _Kernel and _Memory added, which MiniDumpWriteDump needs.
• Release: the Windows build's devstack.pdb ships as devstack-x86_64-pc-windows-msvc-pdb.zip. It is attested and listed in SHA256SUMS. The installer, devstack update, winget and Homebrew keep using their archives by name. docs/releasing.md and the changelog are updated.

No review card: diagnostics and a self-restart within the hub's existing role.

Tests:

• New unit tests: two minutes of silence count as stuck; only an HTTP status line is an answer; a port that accepts and stays silent does not answer; the newest dumps are kept; a dump of the test process is written on Windows (MDMP signature).
• clippy and fmt are clean.
• Not run against a really stuck hub.

🤖 Generated with Claude Code