Support setup teardown/cleanup commands

[cebarks]

Summary

Add optional teardown field to package configuration that runs when a package is undeployed. This is the counterpart to the setup field (which runs initialization tasks on first deploy).

Motivation

The setup command handles one-time initialization (e.g., brew bundle, defaults write), but there's currently no way to undo those operations when a package is removed. Examples:

• Homebrew: setup = "brew bundle" → teardown should run brew bundle cleanup --force
• macOS defaults: setup = "scripts/apply-defaults.sh" → teardown should reset to system defaults
• Systemd services: setup = "systemctl enable myservice" → teardown should systemctl disable myservice

Without teardown support, users must manually undo setup operations when removing packages.

Proposed API

[packages.homebrew]
description = "Homebrew package manager"
setup = "brew bundle --file=~/.Brewfile --no-lock"
teardown = "brew bundle cleanup --force --file=~/.Brewfile"
teardown_shell = "zsh"  # Optional, defaults to setup_shell or "sh"

CLI

# Run teardown for all packages being undeployed
dotm undeploy                    # runs teardown before removing files

# Run teardown only (without undeploying files)
dotm teardown --package homebrew

# Skip teardown during undeploy
dotm undeploy --no-teardown

# Dry run
dotm teardown --dry-run

Design Questions

1. Should teardown run automatically on dotm undeploy?

   • Option A: Always run teardown before undeploy (opt-out with --no-teardown)
   • Option B: Never automatic (separate dotm teardown command)
   • Option C: Configurable per-package (auto_teardown = true)

2. Should teardown track state?

   • Option A: No state tracking (always runs if configured)
   • Option B: Track teardown like setup (hash-based, skip if unchanged)
   • Option C: Track which packages have been "set up" and only teardown those

3. Error handling: Should teardown failure block undeploy?

   • Option A: Warn but continue (teardown is best-effort)
   • Option B: Abort undeploy on teardown failure
   • Option C: Configurable (teardown_required = true)

4. Ordering: Should teardown respect setup_after in reverse?

   • If setup order was A → B → C, teardown order should be C → B → A

Dependencies

• Requires setup command to be implemented first
• Uses same state directory and execution infrastructure

References

• Setup command spec: docs/SPEC-setup-command.md
• Setup implementation plan: docs/PLAN-setup-command.md
• Hooks implementation: src/hooks.rs