v0.7.0

Added

• The tray menu can stop every managed process. Right-click the tray icon and pick
  Stop all processes to halt every dev server DevWebUI runs, without opening the dashboard.
  It calls the same route as the dashboard's Stop all and devwebui stop-all, so it stops the
  servers and leaves DevWebUI itself running; Restart and Quit still act on DevWebUI.

Changed

• Inter is served by DevWebUI, not fetched from the Google Fonts CDN. The shared kit's base
  stylesheet opened with an @import of fonts.googleapis.com, and a remote @import at the head
  of a render-blocking stylesheet blocks first paint on a round trip to the internet. Free on a warm
  HTTP cache, which is why it went unnoticed, but dead time on a first run or after a cache
  eviction, and an outright stall with no network, on a local dashboard that otherwise never needs
  to be online. The two Latin subsets of Inter's variable woff2 now ship under web/public/fonts/.
  Same typeface, no flash of fallback text, and the dashboard renders offline.

Fixed

• A busy port could be reported as having no owner on Windows. portOwners() shells out to
  PowerShell for Get-NetTCPConnection + Get-CimInstance, and the shared capture helper bounded that
  at 5 seconds while RESOLVING WITH WHAT IT HAD on expiry rather than reporting a timeout. Starting
  a PowerShell and making it autoload NetTCPIP and CimCmdlets is ~1.5s warm but goes well past 5s
  cold, so the probe returned an empty string, portOwners() returned no owners, and a port that
  was plainly occupied looked free. diagnose() then downgraded a straightforward port-in-use
  crash to "low confidence, cause unknown" — the exact case the heuristic exists for, failing
  precisely when the machine is busy enough to make port conflicts likely. The Windows probe now
  gets 20 seconds, because here a slow answer beats a confidently wrong one.
  • This is what had CI red on windows-latest on main since 2026-08-03: both port tests were
    landing at ~5010ms, i.e. exactly the internal timeout. The two tests that reach this path also
    now carry explicit timeouts of their own, since the call they make can legitimately outlast
    bun's 5s default.

Internal

• CI and Release can be dispatched manually. GitHub's standard mitigation for an Actions
  incident is to throttle webhook triggers, which means a push lands on origin and no workflow run
  is ever created: nothing goes red, there is simply nothing, and a release stalls waiting on a run
  that will never exist. workflow_dispatch is not throttled alongside the webhooks. Release's
  publish job is additionally gated on github.ref_type == 'tag' rather than on the triggering
  event, so dispatching against a tag ref publishes for real and no dispatch can ever publish for
  the wrong one.