v0.15.1

update works on a global install

pi-outpost update, on a copy installed with npm install -g pi-outpost, answered:

[pi] cannot tell how this copy was installed, so nothing was changed
[pi]   entry: /Users/you/.npm-global/bin/pi-outpost

— and changed nothing. On the ordinary global install, which is the one case the command
exists to automate, and on every machine: this was never specific to a custom npm prefix.

npm puts the command at <prefix>/bin/<name>, a symlink into
<prefix>/lib/node_modules, and that link is the path process.argv[1] carries. It has
no node_modules segment in it, so the global root was never even looked up and
detection fell through to "unknown" — which refuses and prints its evidence, exactly as
it is supposed to when it cannot tell.

The entry is now resolved through its symlinks before it is classified, and the refusal
prints the target as well as the path when the two differ.

The rule itself did not change, and the reasons it is strict have not gone away: a
project's own ./node_modules/.bin/pi-outpost still refuses rather than running
npm install -g against a different copy, an npx cache is still ephemeral rather than
global, and an entry that cannot be resolved classifies exactly as it did before.

Verified against a real npm install -g into an isolated prefix, not only in tests: a
0.14.1 copy upgraded itself to 0.15.0, and a copy already at the newest version now says
nothing to install instead of refusing.

---

Upgrading: this is the release that fixes upgrading, so a copy at 0.15.0 or earlier
cannot pull it in with pi-outpost update — run npm install -g pi-outpost once, and
update works from there. Nothing else changed: @pi-outpost/embed is untouched and
stays at 0.15.0.