feat(support): add phase 1 narrative for logging and rollback

Add literate programming phase 1 documentation for:
- logging.sh: transparency and auditability during operations
- rollback.sh: cleanup strategy after failures

Decision: Plain text logs for readability over structured JSON.
Log destination is /tmp/void-wrapper-YYYY-MM-DD-HHMMSS.log to
avoid conflicts in multi-run sessions. Logs remain ephemeral
in live environment, not copied to target system.

Decision: Three log levels (INFO, WARN, ERROR) with clear
separation between stdout (user-facing) and log file (detailed
trace). Secret masking prevents passphrase exposure.

Decision: Best-effort rollback limited to reversible operations.
Unmount filesystems and close LUKS mappings, but never revert
partitioning or formatting (irreversible without data loss).
Only cleanup after explicit user confirmation.

Rationale: Full automatic rollback rejected due to complexity
and risk. Partial cleanup with clear manual recovery instructions
is safer and more transparent. Track failed phase to provide
targeted recovery advice.

Open questions for phase 2:
- Support verbose/debug mode beyond standard levels?
- Display log path at end for manual review?
- Handle log rotation in multi-run sessions?

src/logging.sh

@@ -0,0 +1,29 @@
+# === Motivation ===
+# Provide transparency and auditability during destructive operations.
+# === Problem Statement ===
+# Users need to see what the wrapper is about to do and what it did.
+# === Scope ===
+# In scope: logging levels, user prompts, and summary output.
+# Out of scope: external logging services.
+# === Concepts ===
+# Plan summary: a preflight printout of intended actions.
+# Log levels: INFO (progress), WARN (recoverable issues), ERROR (fatal failures).
+# Secret masking: never log passphrases or cryptographic material.
+# === Decisions ===
+# Use clear, non-ambiguous wording for destructive steps.
+# Capture a local log file for later review and debugging.
+# Keep logs in the live environment only; do not copy to target system.
+# Log destination: /tmp/void-wrapper-YYYY-MM-DD-HHMMSS.log
+# Use plain text format for readability (not JSON).
+# Distinguish between stdout (user-facing messages) and log file (detailed trace).
+# Prefix log lines with timestamp and level: [2025-01-15 14:23:45] [INFO] message
+# === Alternatives Considered ===
+# Silent mode rejected because it hides risk.
+# === Constraints ===
+# Logging must not expose secrets such as passphrases.
+# === Open Questions ===
+# Should we support a verbose/debug mode for troubleshooting, beyond the standard levels?
+# Should the log file path be displayed to the user at the end for manual review?
+# How should we handle log rotation if the wrapper is run multiple times in the same session?
+# === Success Criteria ===
+# Users can review what happened before and after the installer handoff.

src/rollback.sh

@@ -0,0 +1,28 @@
+# === Motivation ===
+# Reduce fallout if a phase fails mid-way.
+# === Problem Statement ===
+# The wrapper should leave the system in a predictable state after errors.
+# === Scope ===
+# In scope: cleanup expectations and guidance for manual recovery.
+# Out of scope: full automatic rollback of disk changes.
+# === Concepts ===
+# Cleanup: unmounting and closing encryption mappings.
+# Best-effort rollback: undo reversible operations, leave destructive changes as-is.
+# === Decisions ===
+# Rollback is limited to reversible operations only:
+#   - Unmount all filesystems under /mnt
+#   - Close LUKS mappings (cryptsetup close)
+#   - Do NOT revert partitioning or formatting (irreversible without full disk wipe)
+# Only perform cleanup after explicit user confirmation.
+# Provide clear manual recovery instructions if automatic cleanup fails.
+# Track which phase failed to offer targeted recovery advice.
+# === Alternatives Considered ===
+# Full rollback rejected due to complexity and risk.
+# === Constraints ===
+# Cleanup must avoid touching unrelated devices.
+# === Open Questions ===
+# Should rollback be automatic on failure, or require explicit user confirmation?
+# What state should be left after rollback - empty disk, partial setup, or unchanged?
+# Should we provide manual recovery commands if automatic rollback fails?
+# === Success Criteria ===
+# After a failure, mounts and encryption mappings are closed when safe to do so.