[omartelo]

Why

Two Windows users report the same failure: lich freezes, the window stays on screen, the UI stops talking to the backend — and lich.log holds nothing.

Nothing is missing on the crash side. debug.SetCrashOutput has routed panics to lich.log since v0.23.0 (#124, which was this exact shape on Windows), and there is no recover() anywhere, so any panic kills the process and leaves its trace in the log. An empty log therefore says the opposite of what it looks like: it probably did not panic. It hung, or it was killed without one.

For that case lich collects nothing at all. Every diagnostic it has answers the question "is it running?" — none answers "what is it stuck on?".

What

• internal/terminal/transport.go — a token-gated GET /debug/goroutines serving pprof.Lookup("goroutine").WriteTo(w, 2). Deliberately not net/http/pprof: one dump of one thing, not a profiling surface registered on the default mux.
• internal/rage/rage.go — lich rage fetches it into the bundle as goroutines.txt whenever an instance is answering, masked by the same scrub the logs go through. The fetch is bounded at 5s, and a lich that holds its port but will not answer within it leaves that sentence in the file — which is the finding, not a failure of the bundle.
• No dump entry at all when nothing is running: the report already says so.

Nothing else changes, and the endpoint costs nothing until someone asks for it.

Test plan

• go test ./... — 1304 pass, including the new endpoint (200 with the stacks, 401 without the token) and the three rage cases (running, running-but-silent, not running).
• go test -race ./internal/rage/... ./internal/terminal/...
• gofmt -l . clean, go vet ./... clean.
• Cross-compile loop: build + vet for linux, darwin, windows.
• Manual: freeze a session, run lich rage, read goroutines.txt out of the archive.

Frontend untouched, so its gate was not run.