fix: repoint absolute env paths into the worktree

[nemanull]

fix: repoint absolute env paths into the worktree

Closes #18

The problem

wt builds a worktree's env files in three passes: copy each file verbatim from
the main checkout, fill in vars missing from the committed example, then patch
the keys listed in wt.config.json.

That last pass only touches keys the config names. Everything else is inherited
byte-for-byte — including absolute paths that still address the main checkout.

A worktree that runs another checkout's build artifact looks completely healthy:

• The path resolves, so nothing errors.
• The artifact is real and executable, so spawns succeed and health checks pass.
• Port isolation still works, so the service listens exactly where expected.

Only the code behind it is wrong. Every change you make in the worktree is not
what runs, so local verification of that component proves nothing.

The fix

For every absolute value in a seeded env file, find the git working tree that
encloses it by walking up for a .git entry (a directory in a primary checkout,
a file in a linked worktree). Then:

Enclosing checkout	Action
None	Leave alone. /usr/bin/node is shared on purpose.
This worktree	Leave alone. Already correct.
Main worktree, or a sibling worktree	Repoint at the same relative location here, and report it.
Any other checkout	Report it, leave it alone.

No configuration and no key list. That is deliberate: an explicit list of path
keys is exactly what would have prevented this bug, and exactly what will fall
behind again the next time someone adds a key.

Why not just add the key to wt.config.json

The issue suggests that as a companion change. It fixes one instance. An audit of
the repo that hit this found four more keys that break identically the moment
anyone makes them absolute — a RocksDB state directory, a cache directory whose
cleanup job deletes under it, a sync scratch directory, and a test impact graph.
All are relative today. None would be covered by a list nobody remembered to grow.

Scope

• Only files listed in wt.config.json under envFiles are examined.
• Only the path token is touched. Quotes, inline comments, trailing whitespace and
  CRLF line endings are written back verbatim.
• Colon-joined PATH-style values and unterminated quotes are skipped whole,
  rather than half-repaired.
• Checkout roots compare by physical location, so a symlinked spelling of the main
  worktree is still recognised as the main worktree.
• wt env seed is unchanged. It has no worktree to repoint paths at.

Verifying

Reported to stderr, and in --json under envPathEscapes:

wt: rewrote 1 env value that pointed outside this worktree
  server/.env ACCOUNTING_RUST_RUNNER_BIN
    was /home/dev/proj/apps/runner/target/release/runner
    now /home/dev/proj/.worktrees/my-branch/apps/runner/target/release/runner

Run against three real worktrees of the repo that reported this: the two carrying
the escaped value each rewrite exactly one line, and the one a developer had
already hand-repaired is a no-op. No other line in a 132-line env file moves.

docs/env-path-isolation.md documents the failure mode, since a silently wrong
binary is indistinguishable from success in logs.

Repairing existing worktrees

Worktrees created before this still hold the escaped values. Re-run plain
wt setup inside one. Note wt setup --repair short-circuits when there is
nothing else to repair, so it will not do it.