muse does not track the executable (+x) bit — every script loses it on checkout/clone

Summary

muse does not track the executable (+x) permission bit on committed files at all. Any .sh script committed to a muse repo comes back as -rw-r--r-- (not executable) after every fresh checkout, merge, clone, or branch switch — and muse status doesn't even register chmod +x as a dirty change, confirming the bit isn't part of tracked file state in any form.

How this was found

While finishing Phase 4 of musehub staging #185 (disposable sandbox tooling for muse-dev), all three .sh scripts under ~/ecosystem/muse/scripts/dev/ (which-muse.sh from Phase 1, plus the two new Phase 4 scripts) came back non-executable after a routine muse merge + branch cleanup, breaking a test that shells out to sandbox-run.sh directly (PermissionError: [Errno 13] Permission denied).

Impact

Every executable script committed anywhere in the muse/musehub ecosystem is affected — a fresh clone or checkout silently produces broken scripts until someone manually re-runs chmod +x. This is easy to miss (the file's content is fine; only the mode bit is wrong) and will keep recurring for every future script added to either repo, and for anyone who clones fresh (including new contributors following the getting-started docs).

Suggested fix

Track the executable bit as part of a file's tracked metadata (analogous to git's 100755 vs 100644 mode), and restore it correctly on checkout/clone/merge. This is a core object-model change (snapshot manifest entries need a mode field, or equivalent), not a quick patch — scope it properly before starting.

Workaround until fixed

After cloning or checking out a branch with executable scripts, manually chmod +x them. Not sustainable long-term, especially as scripts/dev/ grows per #185's remaining phases.