Improve multi-source workflow discoverability and detect concurrent `listen` sessions

[leggetter]

Problem

As local setups grow more complex, users end up managing multiple Hookdeck connections at once. A common pattern is running one hookdeck listen instance per terminal tab, so a developer working on three connections can have 6–8 terminal tabs open (CLI listeners plus dev servers, AI coding sessions, etc.). This is noisy and hard to manage.

In practice, several users have asked variations of:

Is there a way to get hookdeck listen * working, or have a single instance monitor multiple sources?

The key insight is that the CLI already supports this — a single hookdeck listen instance can forward events for multiple sources via a comma-separated list, or * to listen to all sources:

hookdeck listen 3000 source-a,source-b
hookdeck listen 3000 '*'

The problem is discoverability: users don't realize this capability exists, so they default to running one instance per source.

What we've done so far

PR #303 improves the hookdeck listen -h help text to document the multi-source / * syntax and adds examples. This addresses the documentation gap.

Proposed enhancement (this issue)

Help text alone is passive — users have to go looking for it. We could make the multi-source workflow actively discoverable by detecting when a user is running multiple concurrent listen sessions and surfacing a hint, e.g.:

💡 You have multiple hookdeck listen sessions running. You can forward several sources from a single instance with hookdeck listen <port> source-a,source-b or hookdeck listen <port> '*'.

Open questions / design considerations

• Detection mechanism. How do we reliably detect other concurrent sessions? Options to evaluate:
  • Local lockfile / state file in the config dir that each running listen registers itself in (and cleans up on exit).
  • Querying the Hookdeck API for active CLI sessions on the project.
  • OS-level process inspection (least portable; probably avoid).
• Scope of detection. Per-project only, or any listen on the machine? Likely scope to the same project/profile to keep the hint relevant.
• Cleanup / staleness. Crashed sessions shouldn't leave stale state that produces false hints. Needs a heartbeat or PID-liveness check.
• Noise control. Only show the hint once per session (or rate-limit it) so it doesn't become annoying for users who deliberately run separate instances.
• Opt-out. Consider a flag/config to suppress the hint.

Acceptance criteria (proposed)

• A user running a second concurrent listen session sees a one-time, non-blocking hint about consolidating sources into a single instance.
• No false positives from crashed/stale sessions.
• The hint is rate-limited / shown at most once per session and can be disabled.
• Behavior is covered by tests where practical.

Related

• PR Document multiple sources in listen command #303 — documents the multi-source / * syntax in hookdeck listen -h (the passive half of this).