gt dashboard polling piles up orphaned bd processes until the host hits its process limit

Summary

gt dashboard polls gt mail inbox --json, gt status --json, and gt hooks list every few seconds. Each spawns one or more bd processes. When a bd call stalls, the gt caller gives up after its timeout and exits, but the bd child is not killed. It is reparented to launchd and keeps waiting. The dashboard keeps polling, so the orphans accumulate.

Observed (macOS 15, gt main@649b832 and 1.1.0, bd 1.2.2)

• 2026-09-05 10:09 EDT: 5629 processes on the host against ulimit -u 5333. fork() failing for every shell. 4630 of them were bd with ppid 1 (bd version, bd sql --json SELECT w.id ... FROM wisps ..., bd list --label gt:message ...), all sleeping, all spawned by gt mail inbox / gt status --json / gt hooks list whose grandparent was gt dashboard (running 10h).
• After pkill -9 -x bd the count dropped to ~100 and the same gt mail inbox --json completed in 1s. With the dashboard running the pile regrew to 1486 in ~8 minutes; with the dashboard stopped it stayed flat.
• Dolt itself was healthy throughout (3 connections, 0s latency). The stall is a cascade: once some bd calls are slow, the poll rate outruns them and every new one queues behind.

Suggested fixes

1. When a gt command's bd call times out, kill the child (process group) instead of leaving it.
2. Dashboard: never start a new poll while the previous one for the same endpoint is still running; back off when calls exceed the interval.
3. gt doctor check: warn when more than N orphaned bd processes exist.

Workaround in use

A watchdog kills orphaned bd older than 5 minutes; dashboard runs only when someone is looking at it.