fix: eliminate daemon-env.json — derive env at spawn time

[c-h-]

Summary

• Rewrites buildSpawnEnv() to source ~/.zshenv at spawn time via /bin/zsh -c instead of loading stale daemon-env.json
• Removes saveEnvironment(), loadSavedEnvironment(), and ENV_FILE const from src/utils/daemon-env.ts
• Removes saveEnvironment() call from daemon startup in src/daemon/server.ts
• Simplifies buildSpawnEnv signature (drops unused first param) across all 5 adapter callers
• Adds 6 tests for getCommonBinDirs() and buildSpawnEnv()

Closes #118

Test plan

• npm run typecheck — zero errors
• npm run lint — zero errors
• npm run build — succeeds
• npm test — all 474 tests pass (including 6 new)

🤖 Generated with Claude Code

[c-h-]

Review: CI green, docs clean, one concern before merge.

buildSpawnEnv() does sourceZshEnv() || process.env — if sourcing ~/.zshenv succeeds, it replaces the daemon's process.env instead of merging with it. Any env vars only in process.env (temporary exports, launchd-injected vars, test/runtime vars) get dropped unless they're also in ~/.zshenv.

Issue #118's intended contract was the opposite: start with process.env, layer ~/.zshenv on top, then apply opts.env.

Suggested fix: merge zsh-derived env onto process.env, not replace:

const zshEnv = sourceZshEnv();
const base = { ...process.env, ...(zshEnv ?? {}) };

Add a test proving a process.env-only var survives when sourceZshEnv() succeeds.

[c-h-]

Addressed this review:

• buildSpawnEnv() now starts with process.env, overlays sourced ~/.zshenv, then applies extraEnv
• added a regression test proving a process.env-only var survives when sourceZshEnv() succeeds

Local verification passed:

• npm test
• npm run typecheck