fix(env): prune orphaned lock entries + idempotent UpsertEnv

[fentas]

Problem (refined diagnosis — #174 fixed the wrong mode)

b verify was never clean for a user despite files being byte-identical to upstream. The real cause is duplicate lock env entries, not single-hash drift (which is why #174's auto-heal couldn't fix it).

Their b.lock had two blocks for the same repo:

• git@github.com:kernpilot/lok8s#main — 223 files, configured in b.yaml
• git@github.com:kernpilot/lok8s#kubeone — 115 files, NOT in b.yaml (a leftover from renaming the label kubeone→main)

They share 101 dests. For render.sh, #main records 61d915c4… (matches disk → ✓) while the orphaned #kubeone keeps a stale 1918e425… (→ ✗). Confirmed against their lock: jq '.envs[] | .ref,.label' → both present, only #main in config.

Why nothing healed it:

• FindEnv/UpsertEnv key on the configured (ref,label) = #main, so the orphan is never re-synced or replaced → "(up to date)".
• b verify iterates all blocks → reports #kubeone's stale hashes against files #main owns → 101 mismatches.
• Nothing prunes a lock entry no longer in the config.

Fixes

1. Prune (repair): updateEnvs drops lock env entries whose (ref,label) isn't in b.yaml, before writing the lock — keyed via the same gitcache.RefBase/RefLabel it writes with, so a configured env (even one filtered-out this run or up-to-date) is never pruned. The lock is rewritten on every b update, so a poisoned lock self-heals: orphan removed, verify goes clean. Emits a one-line notice of what was pruned.
2. Idempotent UpsertEnv (prevention): replace the first (ref,label) match in place and drop any further duplicates, so a same-key dup collapses to one on write instead of leaving a stale twin.

Tests

• TestUpdateEnvs_PrunesOrphanedLockEntries — orphan #kubeone removed while up-to-date #main is kept; fails without the prune (reproduces the 2-entry lock).
• TestUpsertEnv_CollapsesDuplicates — pre-existing same-key dups collapse to one.

go build, go vet ./..., gofmt, full go test ./... all clean.

For kubehz-cluster: after this ships, a plain b update --envs-only prunes #kubeone → verify clean. (Pushed over HTTPS via the gh token; ssh-agent has no key this session.)

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR fixes b verify reporting persistent env drift caused by stale/duplicate b.lock env entries by (1) pruning lock env entries that are no longer configured in b.yaml during b update, and (2) making lock env upserts idempotent by collapsing duplicate (ref,label) entries.

Changes:

• Make Lock.UpsertEnv replace the first (ref,label) match and drop any further duplicates.
• Add UpdateOptions.pruneOrphanedEnvs to remove lock env entries not present in the current config before writing b.lock.
• Add regression tests covering orphan-pruning during update and duplicate-collapse behavior in UpsertEnv.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
pkg/lock/lock.go	Makes env upsert idempotent by collapsing duplicate (ref,label) entries.
pkg/lock/lock_test.go	Adds coverage for duplicate-collapse behavior in UpsertEnv.
pkg/cli/update.go	Prunes orphaned lock env entries (not in b.yaml) before writing the lock.
pkg/cli/env_test.go	Adds regression test ensuring b update prunes orphaned env lock entries even when the live env is up to date.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[fentas]

Review loop complete — 2 rounds (Copilot + subagent). Round 1: also dedup same-key lock entries (Copilot). Round 2 clean (Copilot 0 new comments; subagent SHIP). Prunes orphaned + duplicate lock env entries so a poisoned lock self-heals on update; verify goes clean. Regression tests fail without the fix. build/vet/gofmt/test green. Merging.