fix(applications): scan ~/Applications on macOS

[kai-osthoff]

Problem

Apps installed into the per-user ~/Applications folder are invisible to search on macOS.

get_default_app_scan_paths() covers only /Applications and /System/Applications. Installers that don't ask for admin rights write to ~/Applications instead — Autodesk Fusion, some Adobe tools, and the PWA shims Chrome and Edge generate.

This is a platform asymmetry rather than a deliberate choice: the Linux arm of the same function already adds ~/.local/share/applications, and the Windows arm already adds APPDATA. macOS was the only platform ignoring its per-user location.

Evidence

On an affected machine, querying search_index.db before the change:

	before	after
entries from ~/Applications	0	10
Autodesk Fusion findable	no	yes
applications indexed	246	256

Change

Appends ~/Applications to the macOS defaults, mirroring how the Linux arm resolves its per-user path via dirs::home_dir(). No new dependency.

is_default_app_location() derives from the same function, so ~/Applications now also counts as a default location — the settings UI will correctly reject it as a redundant custom scan path for users who added it manually as a workaround.

Worth flagging

Scanner::scan_directory recurses, so this also picks up bundles nested inside ~/Applications subfolders. On the machine above that meant 6 extra entries beyond the 4 top-level ones, from Chrome Apps.localized, Edge Apps.localized, and a vendor subfolder — all of them genuinely launchable apps.

For users with many PWAs this could feel noisy. Two mitigations already exist: individual apps can be disabled via applicationEnabled in the Applications tab, and the recursion behaviour is unchanged from how custom scan paths have always worked. Happy to restrict the new path to a non-recursive scan if you'd prefer that trade-off.

Tests

Two tests added, both verified failing before the change and passing after:

• test_get_default_app_scan_paths_includes_user_applications
• test_is_default_app_location_macos_matches_user_applications

cargo test --lib application:: → 97 passed, 0 failed. cargo clippy clean (the two remaining warnings are pre-existing: the ext-builder sidecar placeholder and a block v0.1.6 future-incompat in a transitive dep). cargo fmt --check clean.

[Xoshbin]

Thank you for your contribution.
I did review the pr yesterday but Github's actions had issues since then and still, that is why the merge delayed.