feat(init): watchdog: pinger thread PINGs servers (framework answers, no server code), main kills after 5s unanswered -> crash path; not pinged: terminal, pm (handlers wait for user); give-up drains queued ping; spawntest hang check

docs/ipc.md

@@ -136,6 +136,15 @@ it holds the key and every grant. Init's main thread never waits on a
 server it restarts: its own output goes through a thread of its own
 (`init/src/output.rs`), which waits on the log server instead.
 
+Hangs are noticed by pinging (`init/src/watchdog.rs`): another thread of
+init's calls each server with `server_framework::PING` every 2 s, which
+the framework's loop answers without the server's code. A ping
+unanswered for 5 s means the server is stuck in a handler; init kills it,
+and the death is handled as a crash, so the restarted server answers the
+still-queued ping. The terminal and the permission manager are not
+pinged: their handlers wait for the user (`READ`, a consent prompt),
+which a ping cannot tell from a hang.
+
 A program's `uses` endpoints arrive as badged copies with `Execute` and
 `Delegate`: the badge (unique per copy) tells the server which client is
 calling, and `Delegate` lets the client send capabilities with its calls