Add file attribute tracking TODO to PLAN.md

Document planned approach for capturing and restoring file metadata
(permissions, mtime, uid/gid) alongside content deltas. Notes the need
for a pluggable attribute backend due to filesystem differences, and the
requirement to fail loudly on incompatible attributes during restore.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

PLAN.md

@@ -180,6 +180,28 @@ other. Approaches that could address this:
 
 These are significant complexity increases and out of scope for now.
 
+### File attribute tracking (TODO)
+
+Currently the manifest records only file content changes. File metadata (permissions, mtime,
+ownership, xattrs) is not tracked, meaning restore cannot faithfully reconstruct the original
+state.
+
+**Planned approach:**
+- On each run, compare attributes between PREV and PEND for every file in the change list
+- Encode attribute changes explicitly in the manifest alongside content changes
+- Restore walks the delta chain applying both content deltas and attribute deltas in sequence
+
+**Design considerations:**
+- `fs.stat()` gives mode, mtime, uid, gid — but not xattrs, ACLs, or fs-specific attributes
+- Attribute richness is highly filesystem-dependent (ext4, btrfs, APFS, NTFS all differ)
+- Need a pluggable attribute backend, similar to the delta backend, so the attribute set captured
+  and restored can be tuned per deployment without changing core logic
+- Restore must handle the case where an attribute from an older delta is no longer representable
+  on the target filesystem (e.g. restoring to a different fs type) — fail loudly rather than
+  silently skip
+- rsync `-a` already preserves attributes into PEND, so PEND is always the authoritative source
+  of truth for what attributes should be at that point in time
+
 ## Occasional Snapshots
 
 Delta chains are efficient but fragile over long chains. Periodic full snapshots (every N deltas,