test(cli): teach the host-anchoring sweep one more hop — an import alias to a literal in a sibling module (#12582)

`serve-cluster-host-resolution.test.ts`'s `resolveIdentifier()` knew two
spellings, both confined to `serve.ts` itself: `const X = '<literal>'` and
`const X = Serve.MEMBER`. So single-sourcing a package spelling into a module
`serve.ts` shares with another reader turned that load from "app-declarable,
host-anchored, checked" into "unknowable" — and an unresolved specifier drops
OUT of the judged population rather than into it, silently.

Add a third hop: follow an import alias to a string literal in a sibling module
of the SAME package, consulted at the three points the resolver would otherwise
return `undefined` (the call-site identifier, `const X = <alias>`, and
`static readonly MEMBER = <alias>`).

It can only widen. It runs where the resolver already gave up and returns a
literal or `undefined`, never a different literal; a `const X = <identifier>`
becomes a candidate only when the name is one this module imports, so an
unresolvable nearer binding can never shadow a farther literal and take a site
out of the swept population.

The fence is the package, not the filesystem: a bare specifier, a relative path
that escapes the package, a re-export, a namespace import, a type import, a
missing sibling and a non-literal export are each refused, with a case for each.

No live site uses the hop yet — that is deliberate, and the consumer is a
follow-up. Measured either side of this change, the swept population is
byte-for-byte identical: 43 load sites, 4 app-declarable, 8 unresolved.


Claude-Session: https://claude.ai/code/session_01UjujZN219uFzBhSYfMykCd

Co-authored-by: Claude <noreply@anthropic.com>

Author: os-litant