Cover macOS manager updates beside apps with framework links

[seltzdesign]

Problem

On macOS, updating 0.8.1 → 0.9.0 from /Applications fails and rolls back:

Manager update failed: Update failed; the previous manager was restored: Archive contains a linked path: /Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Electron Framework. Recovery files: /Applications/.craft-manager-update-…

The swap is performed by a copy of the previous manager. In 0.8.1–0.8.3, adopt_updated_portable calls files::no_links(base), which walks the whole application folder. Any other app with framework symlinks (Electron apps such as VS Code, plus many others) makes the launch step fail after the new bundle is published, so swap_macos restores the old one. Each attempt leaves a ~66 MB .craft-manager-update-* folder behind. It only happens when portable.txt is not beside the app, because the early local_storage return skips the scan otherwise.

0.9.0 (3ea87ef) already limits the check to the folder itself and its metadata files. This PR keeps that from regressing and helps users who are already stuck.

Changes

• Regression test full_apply_ignores_links_inside_other_applications: runs apply_macos_with end to end with a sibling Other.app containing a framework symlink, and asserts that the update is published, previous.app is kept, the sibling link is untouched and the result is launch_requested. With the 0.8.1 no_links(base) call restored, this test fails with the reported error. Until now no full-apply test exercised a successful swap.
• Error wording: files::no_links also guards installed bundles and staging folders, so "Archive contains a linked path" pointed at the wrong cause. It now says "Linked path is not allowed: …".
• docs/macos.md: explains that 0.8.1–0.8.3 cannot update themselves beside such apps, and that those users must replace the app manually from the latest release once. It also notes that the leftover recovery folders can then be removed.

Testing

• cargo test --lib self_update: 28 passed on macOS.
• cargo test -- --test-threads=1: 202 passed, 1 failed. The failing test, updates::planning_tests::custom_destination_keeps_pinned_release_and_rejects_a_late_folder_collision, fails the same way on unmodified main, so this change didn't cause it. A parallel cargo test run also shows ~24 failures from shared state in portable/settings/updates tests, again on unmodified main.

🤖 Generated with Claude Code