Multi-host routing: registry rejects unregistered hosts (no github.com fallback)

[goldenwitch]

Problem

DispatchContext::adapter_for falls back to the default github.com adapter for any unregistered RepoHostId. Combined with daemon_cli::run_up only ever registering github.com, the daemon silently mis-routes GHE / Azure DevOps requests through the github.com adapter.

The advertised "multi-host" routing is therefore non-functional for any host other than github.com.

Evidence

• crates/devdev-cli/src/daemon_cli.rs:339-349 — only github.com is registered.
• crates/devdev-daemon/src/dispatch.rs:105-114, 299-334 — adapter_for returns the default adapter on miss instead of erroring.
• ensure_monitor_pr_task (crates/devdev-daemon/src/dispatch.rs:417-435) compounds the bug: it rebuilds PrRef as owner/repo#number, which PrRef::parse treats as github.com regardless of the originating host id. Auto-created monitor tasks for non-github events are reclassified as github.com and stop matching subsequent events.

Acceptance criteria

1. RepoHostRegistry is built from the credentials available in CredentialStore — one adapter per credentialed host. No default fallback.
2. adapter_for(host) returns Err (not the default adapter) when the host is not registered. repo/watch for an unregistered host fails loudly with a message naming the missing credential and how to provide it.
3. ensure_monitor_pr_task constructs PrRef directly from (host_id, owner, repo, number) — no shorthand round-trip.
4. Acceptance test: repo/watch dev.azure.com/foo/_git/bar/pullrequest/1 against a daemon with only github.com credentials returns an error.

Notes

Surfaced by dogfooding PR #3.