fix(atlas-lib): prune stale LVM device entries on force-released teardown

[boddumanohar]

Summary

Q5 in design-issue-277-client-side-compression.md: the node's LVM devices file (/etc/lvm/devices/system.devices, which restricts LVM's default device visibility) never gets pruned after a device disappears, so a node accumulates one stale entry per failure cycle over its lifetime.

lvmVolumeGroup.Release (atlas-lib/volstack/layers/lvmvolumegroup.go) already has the right force path for this: when vgchange -an fails because the backing device vanished without a clean unstage, it falls back to removing the orphaned device-mapper nodes directly (Manager.RemoveOrphanedDMNodes). That's exactly where the stale system.devices entry is also known to be stale, so this adds the pruning step there.

Changes

• Manager.ForgetDevice (atlas-lib/lvm/devices.go): a new primitive, lvmdevices --deldev <path>, scoped to the device the same way CreatePhysicalVolume/RemovePhysicalVolume are.
• lvmVolumeGroup.Release now calls it, once per device it was handed, after falling back to the device-mapper cleanup. It's best-effort: a failure is logged (warnf, matching atlas-lib/lvm/vdo's own Logger convention, introduced here for volstack/layers since it didn't have one yet) and does not fail Release — this is hygiene, and it must never turn a routine unstage into a failed one.

Testing

Followed this repo's red-first workflow: added TestManager_ForgetDevice and TestLVMVolumeGroupReleaseForgetsDevicesOnTheForcePath first, confirmed both failed (the first on a missing method, the second because the layer's Release didn't call it yet), then implemented.

• go test -race ./lvm/... ./volstack/... — all green, including a new test that Release still succeeds when ForgetDevice itself errors.
• golangci-lint run ./lvm/... ./volstack/... — 0 issues.
• make test fails locally, but on an unrelated, pre-existing issue: its vet target pulls in a buf-generated dependency chain that tries to fetch github.com/google/cel-go and the environment here can't reach it. Not something this change touches.

One thing worth flagging before merge: I don't have lvm2/lvmdevices available in this environment, so I could not verify against a real system what lvmdevices --deldev actually prints when a device isn't in the devices file. ForgetDevice doesn't special-case that (no isNoXxx-style error matching, unlike this package's other idempotency helpers), and the caller in Release treats any failure as best-effort/logged rather than fatal, specifically to sidestep needing to know that exact text. Worth a quick live check before this ships, the way this package's other isNoXxx helpers were confirmed against a real cluster.

Out of scope, flagged separately

While reading fabric.go for this, Observe returns StateAbsent with an empty Artifact{} when a device has vanished from the kernel entirely (not just unreachable). lvmPhysicalVolume.Observe and lvmVolumeGroup.Observe both hard-error on zero devices below them ("the layer below exposes no device[s] to..."), and Down's survey() aborts on the first Observe error. That would mean a total, complete device loss on a volume with an LVM stack fails teardown outright, rather than reaching the force path this PR extends — which seems to work against design-node-volume-stack.md §7.4's stated goal that bring-down "tolerates a dead foundation." Not verified against a live cluster, not fixed here — a separate investigation.

🤖 Generated with Claude Code

[boddumanohar]

Folded into #402 directly (Manager.ForgetDevice in atlas-lib/lvm/devices.go, wired into lvmVolumeGroup.Release's force path, same behavior covered by tests there). Closing in favor of #402.