fix(types): a location install's refusal states the LIMIT, not a false install remedy

`createHostImporter`'s ESM-only fallback finder refuses a `link:` / `file:`
install whose linked manifest names something other than the declaration key —
correctly, and deliberately, since a location specifier carries no package name
to expect and accepting the directory anyway would trade a wrong REMEDY for a
wrong LOAD. It reported that refusal with the `declared-unresolvable` INSTALL
wording, every remedy of which is measurably false for this shape: the finder
had just read the manifest at `node_modules/<key>`, so the package is on disk,
was not pruned, and its `import` target exists.

The refusal is unchanged — same kind, same `MODULE_NOT_FOUND`, same exit path,
same accept set. Only the words change: the message now states the directory it
consulted, the name found there, the name expected, why a location specifier
leaves it only the key, and the remedy that works (make the two names agree,
from either end — both pinned as loading).

The second verification axis the card also proposes — comparing
`realpath(node_modules/<key>)` against the declared location, which would make
these installs LOAD — is deliberately not built here.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015QE8qk46e5CHJxyQEUjbf8

Author: claude

.changeset/host-importer-location-install-diagnostic.md

@@ -0,0 +1,11 @@
+---
+"@objectstack/types": patch
+---
+
+`createHostImporter` stops prescribing an install repair for a `link:` / `file:` install that is already correct. The refusal is unchanged; only its wording is.
+
+A host app declaring `{"foo": "link:../bar"}` links `node_modules/foo` to a directory whose manifest may be named anything. `link:`, `file:` and git or tarball URLs name a LOCATION or a remote artefact, never a package, so the specifier carries no name for the ESM-only fallback finder to expect and the KEY stays the expectation — kept deliberately, because widening it would accept any directory sitting at the key and trade a wrong REMEDY for a wrong LOAD. When the linked manifest names something else the finder therefore refuses, and it was reporting that refusal with the `declared-unresolvable` INSTALL wording: run `pnpm install`, check a production prune did not drop it, check the dist was built. Driven on a real symlinked install, all three are measurably false — the finder had just read the manifest at `node_modules/foo`, so the package is on disk, was not pruned, and its `import` target exists. The operator reinstalls, nothing changes, and they go looking for a build that is not broken.
+
+That sub-case now states what was actually measured: the directory it consulted, the name the manifest there carries, the name it expected, and why a location specifier leaves it with only the key. It says outright that this is neither an install nor a declaration problem, and closes with the remedy that does work — make the two names agree, by declaring the linked package under its own name or by renaming the linked manifest to the key. Both ends are pinned as loading.
+
+Unchanged: the refusal itself, its `declared-unresolvable` kind, its `MODULE_NOT_FOUND` code and every consumer branch that reads them; the finder's accept set, which is byte-for-byte what it was — a `link:` install whose manifest matches the key still loads silently, and a plain range or an `npm:` alias whose directory holds a different package still gets the INSTALL wording, because there the install really is the fault. The second verification axis that would make these installs LOAD (comparing `realpath(node_modules/<key>)` against the declared location) is deliberately not built here.