harden: skill snapshot lifecycle — GC superseded snapshots; handle deps installed after register

[nhuelstng]

Duplicate check

• I have searched the existing issues

Context / Summary

Follow-up to #209 (execute-from-approved-snapshot). Adversarial review of #212 surfaced two lifecycle gaps that are not security holes but are real ops/compat concerns.

Problem / What

1. Unbounded disk growth. Approvals are additive and omac register --force with changed code adds a new (name, hash) snapshot (a full copy of the tree, incl. node_modules/.venv) without retiring the old one. Only omac deregister GCs, and only the exact current hash. Iterative re-registration of a heavy skill accumulates full copies under ~/.config/omac/skills/. (internal/cli/register.go, internal/skilltrust/snapshot.go.)
2. Deps installed after register are not in the snapshot. The snapshot is frozen at omac register time, but omac prints install scripts as a next step and never runs them; config.BundleHash excludes node_modules/.venv/dist, so register --force after install is a no-op (same hash → Snapshot short-circuits). A skill that vendors deps into its own dir then imports them would spawn from a snapshot missing them. Documented as a caveat in CREATING_A_SKILL.md, but omac could handle it.

Suggested fix / Ask

• On re-approval of a (name) under the same skillDir, GC snapshots for hashes no longer referenced by any registry entry (and consider retiring superseded approvals to also address the rollback surface noted in harden(security): authenticate the omac control plane (deactivate DoS; per-caller identity) #210).
• Either snapshot AFTER the install step, or offer omac register --resnapshot/re-run to recapture; or detect a stale snapshot (present deps in workdir, absent in snapshot) and warn.
• Surface snapshot size/location on register and reclaimed space on deregister (UX).

Non-goals

• Changing the security boundary (snapshot stays the enforcement point).