muse bundle unbundle skips writing objects that already exist on disk, even if their content is corrupted

Summary

muse bundle unbundle treats an object as "already present" purely by checking whether a file exists at its expected path — it never re-validates the file's actual content against its claimed object ID. If a local object is corrupted (content doesn't match its filename/hash) but a file still exists at that path, unbundle silently skips writing the correct content from the bundle, counting it as "already present" rather than repairing it.

Impact

Found while building musehub staging #185 Phase 5's restore_from_bundle (backup restore tooling): restoring from a bundle onto a corrupted .muse/ store did not actually fix the corruption, because unbundle's object-write step short-circuited on path existence alone. Worked around locally in the restore tool (wipe + reinit .muse/ before unbundling, so nothing is "already present" and everything gets written fresh) — but the underlying CLI behavior is still there for anyone using muse bundle unbundle directly as a repair mechanism, which is a reasonable thing to expect it to do.

Suggested fix

In muse bundle unbundle's object-write path, when a target path already exists, verify its content hash matches the expected object ID before skipping the write. If it doesn't match, overwrite with the bundle's (already-integrity-checked, since --verify can be passed) content instead of silently leaving the corrupt file in place. Add a regression test: unbundle a valid bundle onto a store containing one deliberately corrupted object at a path the bundle would also write to, and assert the object is repaired (correct content) rather than left corrupted.