GHE host classification only matches ghe.*/github.* prefixes; custom corp hostnames fail

[goldenwitch]

Problem

RepoHostId::classify_host only recognizes GitHub Enterprise hostnames if they start with the literal prefix ghe. or github.. Common corporate-named GHE deployments (code.acme.internal, git.example.com, etc.) classify as None.

Downstream impact: PR ref parsing fails, devdev_ask host resolution fails, and registry URL lookup fails — even when the user has explicitly registered that host in the registry. The classification step happens before the registry is consulted, so explicit configuration cannot override it.

Evidence

• crates/devdev-integrations/src/host.rs — classify_host uses host.starts_with("ghe.") || host.starts_with("github.") as the GHE heuristic.
• The matching prefix heuristic is also overly broad in the other direction (e.g. ghe.attacker.com matches), though the security risk only matters if classification gates credential routing.

Acceptance criteria

1. Classification consults the registry of explicitly-registered hosts before applying any heuristic. Explicit configuration wins.
2. Heuristic is restricted to known stable patterns (*.ghe.com, *.github.io) and dropped for the generic ghe. / github. prefix.
3. Acceptance test: an explicitly-registered GHE host with hostname code.acme.internal is classified correctly; an unregistered ghe.attacker.com is not.

Notes

Surfaced by dogfooding PR #3. Related to but distinct from the multi-host routing issue: even when routing is fixed, classification has to succeed first.