env sync prints a full add plan but writes no files in a synthetic project

[fentas]

Observation, not a diagnosis — I could not explain it and it reproduces on shipped v4.18.5, so it is unrelated to #182.

Repro

```bash
mkdir -p /tmp/p/.bin && cd /tmp/p
printf 'binaries: {}\n' > .bin/b.yaml
b -c /tmp/p/.bin/b.yaml env add 'git@github.com:owner/repo#someprofile'
b -c /tmp/p/.bin/b.yaml update --envs-only
```

What happens

• The plan renders correctly: `(new) → ` followed by `+ add` rows for all 243 files.
• No files are written anywhere — not under the project root, not under the config dir. Only `.bin/b.lock` appears.
• `.bin/b.lock` records a `sha256` for `.bin/b.yaml` that does not match the file on disk, i.e. a hash was computed for content that was never written.
• With `-y --safety auto`, every row flips from `add` to `keep` (243 keep) and still nothing is written.
• Same with and without `git init` in the project.
• A watcher polling the target file every 20ms across the whole sync sees no modification at all.

Tracing `SyncEnv`, a first sync has no previous lock entry, so `localChanged` stays false and the `!localChanged` branch should call `writeFile` whenever the target hash differs from on-disk (pkg/env/env.go:437-442) — which it does here. So I expected a write. I did not get far enough to say which guard actually skips it.

Possibly just a missing piece of setup on my side (`PATH_BASE`-style dest root, or something `env add` normally records that I did not). Filing because the failure is silent: a plan claiming 243 adds while writing nothing is indistinguishable from success in a script.

Component behaviour is fine — `filterContent` + `spliceYAML` on a real config with real selectors produce exactly the right bytes.

[fentas]

Retracting this — my report was wrong, and I want to correct the record.

The files WERE written. They went to $PATH_BASE, not to the project I thought I was testing in. My shell had PATH_BASE=/mnt/scratch/github/kernpilot/kubehz-cluster exported from a profile, so b anchored every destination there while my scratch directory stayed empty and I read that as "wrote nothing". -c <path> and cwd both being the scratch dir did not override it. The lock's sha256 not matching the on-disk file was the same thing: it recorded the hash of what it wrote at the real destination.

Everything else follows: the 243-file plan was accurate, the sync worked, and the b.yaml splice worked (it rewrote the vendored env in that project, which is how I noticed).

Sorry for the noise. Closing.

The one thing possibly worth keeping: when -c names a config, the destination root can still come from elsewhere, and the plan prints destinations relative, so there is nothing in the output that reveals where files are actually going. An absolute destination in the header — or a line naming the resolved root — would have made this self-evident instead of looking like a bug. Happy to open that as a separate UX issue if you think it is worth it.