[CalvinAllen]

Summary

When a shim can't resolve a version, it falls back to the next match on PATH. That lookup skipped only ShimsDir(), which comes from DTVEM_ROOT or the home directory. When a process ran with a different home than the one the shims on PATH were installed under, the real shims directory wasn't skipped, so the shim found itself and launched itself. That chain grew to thousands of processes and exhausted memory.

This PR applies both fixes the issue suggests.

1. The fallback lookup excludes the running shim

• New path.LookPathExcludingSelf(execName, self) skips the directory of the running executable (os.Executable(), symlinks resolved) and any candidate that os.SameFiles it. This works whatever the environment says the home is.
• Both shim fallbacks use it: no configured version, and leftover/unknown shim.
• LookPathExcludingShims keeps its behavior for migration detection; it does not skip the dtvem binary's own directory, which may be a shared bin dir. Its directory comparison now also matches different spellings of the shims directory: trailing separator, . segments, case, and, through os.SameFile, 8.3 short names and symlinked paths.

2. Recursion guard

• Before handing off, a shim sets DTVEM_SHIM_FALLBACK=<path it is launching>. A shim that starts and finds itself named there was launched by another shim's fallback, so it exits with an explanation instead of looping.
• The marker names a file, not a shim name as the issue sketched (DTVEM_SHIM_ACTIVE=node). A name-based marker is inherited by every descendant, so a real system node reached through the fallback that runs a script spawning node again would be wrongly refused. With a path, that nested shim is not the file named, so it runs normally.
• The guard is needed beyond fix 1 when two dtvem shim directories are on PATH and neither matches the environment. Each shim then skips only itself and finds the other, and without the guard they would launch each other forever.

On the MCP trigger in the issue

A likely cause, not verified: the launch environment had no USERPROFILE. os.UserHomeDir() then fails, ShimsDir() returns "" so nothing is skipped, and getRootDir() falls back to ./.dtvem in the working directory, so resolution fails too. Fix 1 covers that case because it doesn't depend on the home directory.

Tests

• path: LookPathExcludingSelf (own dir, hard link to self, the old self-finding lookup when no self path is given), shims dir written differently (trailing separator, dot segment, case on Windows, symlink where supported), and SameFile.
• cmd/shim/fallback_test.go: end-to-end tests that run copies of the test binary as real shim processes. TestMain caps the chain at 8 hops, so a regression fails the test instead of fork-bombing CI. Cases:
  • home differs and nothing else is on PATH: clean "no system installation" error
  • a real executable further down PATH: it runs and receives the marker
  • two shim directories: the guard stops it
  • a real executable that runs node again: not mistaken for the loop
• With the old lookup and no guard, all four end-to-end tests hit the hop cap (exit 99), so they catch this bug.
• Format, lint and the full test suite pass locally on Windows.

Resolves #279