feat(bundle): use tauri-native resources + dynamic bundle path detection

[TimeToBuildBob]

Summary

Draft PR to evaluate Tauri-native .app bundling as a replacement for build_app_tauri.sh in the activitywatch repo.

Raised by @ErikBjare in ErikBjare/bob#546:

"Why aren't we using Tauri's way of producing .app bundles and including the "modules" as sidecars or similar?"

Changes

tauri.conf.json — resources injected at build time (not statically configured)

Initially this PR added static bundle.resources to tauri.conf.json, but that broke standalone aw-tauri CI because the paths (../../dist/activitywatch/*) only exist when aw-tauri is used as a submodule inside the activitywatch repo.

Per 1dbc66b, those static entries were removed. Instead, the activitywatch build system injects resources at build time via --config:

cargo tauri build --config '{"bundle":{"resources":{
  "../../dist/activitywatch/aw-server-rust": "modules/aw-server-rust",
  "../../dist/activitywatch/aw-watcher-afk": "modules/aw-watcher-afk",
  "../../dist/activitywatch/aw-watcher-window": "modules/aw-watcher-window",
  "../../dist/activitywatch/aw-watcher-input": "modules/aw-watcher-input",
  "../../dist/activitywatch/aw-notify": "modules/aw-notify"
}}}'

This keeps aw-tauri self-contained (CI-friendly) while still letting activitywatch drive the bundling.

dirs.rs — dynamic resource path detection

Replace the hardcoded /Applications/ActivityWatch.app/Contents/... discovery paths with runtime detection via current_exe():

// Contents/MacOS/aw-tauri  →  go up two levels  →  Contents/Resources
if let Ok(exe_path) = std::env::current_exe() {
    if let Some(contents_dir) = exe_path.parent().and_then(|p| p.parent()) {
        let resources_dir = contents_dir.join("Resources");
        if resources_dir.exists() {
            discovery_paths.push(resources_dir.join("modules")); // tauri-native layout
            discovery_paths.push(resources_dir.clone());          // legacy compat
        }
    }
}

Why this matters: The old code only worked when installed at /Applications/ActivityWatch.app. Users who move the app to ~/Applications/ or run it from a downloaded DMG had no module discovery. This change is independently valuable regardless of the bundler decision.

What's NOT changed here

The Python.framework signing complexity (the #1254–#1256 series) is independent of the bundler. PyInstaller copies Python.framework as separate inodes → needs canonical signing regardless of whether build_app_tauri.sh or tauri build creates the .app.

What's still needed (activitywatch side)

The companion change in activitywatch would replace build_app_tauri.sh with cargo tauri build (with the --config flag above):

# Makefile: replace
scripts/package/build_app_tauri.sh
# with
cd aw-tauri && cargo tauri build --target universal-apple-darwin --config '{"bundle":{"resources":{...}}}'

CI would also need updating to use Tauri's signing/notarization flow (or keep the existing xcnotary approach, applied after tauri build).

Evaluation questions

1. Does bundle.resources with directory paths work correctly with PyInstaller output (which includes nested Python.framework)?
2. Does Tauri's bundler auto-generate Info.plist fields we currently set manually in build_app_tauri.sh (CFBundleURLTypes, LSUIElement, etc.)?
3. Is cargo tauri build fast enough vs the current shell script approach?

Draft status — not ready to merge, but enough to evaluate the direction.

[ErikBjare]

Update the description to note 1dbc66b

[TimeToBuildBob]

Done — updated the description to note commit 1dbc66b and explain the new approach (build-time injection vs static resources in ).