fix(security): reconcile stale protect-* devices on persistent reuse (#610)

[mensfeld]

What

Repro-first for #610. Adds 4 integration tests (tests/git_hooks/test_issue_610_stale_protect_devices.py) that reproduce the persistent-container stale protect-* device wedge. Draft: these are intentionally RED — they assert the post-fix contract and fail today, so CI going red is the signal the bug is still live. No xfail; they flip green once the fix lands.

The bug (confirmed by code-trace)

On reuse/restart of a persistent container, the reuse branches in internal/session/setup.go (~L235 running-reuse, ~L252 stopped-restart) reconcile only port devices (RemoveStalePortDevices). They never re-run SetupSecurityMounts and never strip/reconcile protect-* disk devices. So if a protected path is removed from the workspace while the container is stopped, the container keeps a protect-* device whose source= is now missing, and the next start fails Incus start-validation with Missing source path. A fresh coi run does not self-heal it — recovery needs a manual incus config device remove <container> protect-*.

The fresh-launch case in #610's title is already handled (materialization creates the paths before attaching devices); the genuinely open defect is this reuse-path reconcile gap.

Tests (each a distinct facet)

• test_restart_after_removing_materialized_dir — remove a materialized default dir (.husky) while stopped → restart must succeed.
• test_restart_after_removing_materialized_file — remove a materialized default file (.claude/settings.json) → restart must succeed.
• test_protection_reestablished_after_restart — after restart, the path must be re-materialized and re-protected (read-only in-container), not just booting. Pins against silent protection drift.
• test_restart_after_removing_user_additional_protected_path — same for a user additional_protected_paths entry (.idea), proving the gap is not limited to auto-materialized defaults.

Next

Fix belongs on the reuse branches: a RemoveStaleProtectDevices pass mirroring the port one, or re-running SetupSecurityMounts before Start() so disk devices reconcile against the current workspace. Fix comes in a follow-up once these repros are confirmed red in CI.

Refs #610

[mensfeld]

Pushed the fix (3a9d210): ReconcileProtectedDevices on both reuse branches before Start() — re-materialize COI default paths (protection preserved), remove device for user-added paths. The four repro tests above now assert the fixed behavior and should flip green; added a Go unit-test matrix for the reconcile decision + Manager.GetDeviceSource. Local: build, go vet, gofmt, golangci-lint (0 issues), and the Go unit tests all pass. Marking ready.

[mensfeld]

Security hardening (8edff07)

Self-review of the reconcile surfaced a real issue in where it was wired, so tightening it:

• The reconcile was called on both reuse branches. The already-running reuse branch (resume / post-reboot restore) has no Start(), so it never hits the Missing source path start-validation this fixes — but calling RemoveDevice there would hot-unplug a read-only protect-* device from a live container, dropping protection mid-session (a source that vanished while still mounted keeps writes blocked; removing the device reopens it to a possibly-malicious agent).
• Reconcile now runs only on the stopped→start branch, before mgr.Start(). Doing nothing on the running branch is strictly safer and loses nothing (re-materialize is a no-op against a live mount; the wedge only occurs at start).

Re-materialize-vs-remove logic is unchanged and remains safe: default paths are re-materialized as empty + re-protected (Finding 2 preserved); user paths are removed only when already gone host-side (= fresh-launch semantics). The container can't self-trigger either — protected paths are busy mount points it can't rm/rmdir from inside.