fix(sync): content-hash change detection via a name-encoded marker (#102)

[arimxyer]

Problem

SmartPull decided "did the remote change?" purely from (ModTime, Size) (internal/sync/sync.go). Because the vault is AES-GCM (ciphertext length = plaintext length + fixed overhead), a same-length remote edit — rotating a password to an equal-length one, flipping a fixed-width field, editing a same-width timestamp — keeps Size byte-identical, leaving ModTime as the only signal. Some rclone backends preserve ModTime poorly (coarse granularity, synthesized at upload).

That same comparison gates conflict detection, so a false "unchanged" on a write path (add/update/delete) skips conflict detection entirely → the blind SmartPush overwrites a real remote change → silent cross-device data loss. Low probability, high severity — exactly what you don't want in a password manager.

Fix — pass-cli's own sha256, for zero extra round-trips

rclone lsjson --hash returns the backend's hash, not ours, so it can't be compared to the LastPushHash sha256 we track. Instead:

• On push, write a zero-byte marker named vault.enc.<sha256>.synchash into the vault dir; rclone sync carries it to the remote alongside vault.enc.
• On pull, read the remote content hash straight from the marker's name in the single rclone lsjson listing SmartPull already fetches — no extra network call (doesn't regress Reduce (and surface) pre-unlock sync latency: SmartPull does a silent network round trip on every command #96, doesn't fight perf(sync): overlap pre-unlock remote probe with unlock to hide latency (split from #96) #103).

Detection becomes:

• marker present → remote changed iff markerHash != LastPushHash (content-authoritative; ignores modtime noise, so no false conflicts).
• marker absent → fall back to the legacy (ModTime, Size) heuristic (existing vaults / devices that pushed before markers existed).

SmartPush writes exactly one marker and removes any stale one, so the dir — and, after sync, the remote — holds a single current marker.

Known limitation (documented in code)

An interrupted remote push that uploaded vault.enc but not the marker leaves a stale marker that reads as "unchanged"; the next successful push self-heals it. Accepted in exchange for zero-round-trip, false-conflict-free detection. A user will see one *.synchash object in their bucket — documented in the sync guide as expected and safe.

Tests

• parseRemoteMarkerHash: present / legacy-absent / backup-lookalike ignored / ambiguous-falls-back.
• The fix(sync): modtime+size change-detection can miss same-size+same-modtime remote edits (risk of silent clobber) #102 regression: identical Size+ModTime but a differing marker → detected as changed (the false-negative the issue is about).
• Marker authoritative skip on modtime noise; marker conflict; SmartPush writes & cleans the marker.

All unit + sync integration tests green.

Closes #102.

🤖 Generated with Claude Code