fix(plugins): scan once per change, not once per node, from an on-disk cache

[Horuse]

What does this PR do?

Fixes the pipeline editor hanging for minutes when a pipeline has several plugin nodes (#60). Every plugin node ran its own full scan on mount, loading every installed CLAP/VST3 binary (VST3 on the main thread).

• One shared scan. All nodes use one plugin list (pluginCatalog). A saved node triggers at most one scan per session to check that its plugin is still installed, and shows its stored name meanwhile. Opening a dropdown refreshes the list.
• On-disk cache. plugins.json in the app cache dir. Only new or changed bundles are opened; removed ones are dropped.
• Failures are retried, crashes are not. A bundle that fails to load is not cached, so the next scan tries it again. A bundle that crashes the app while being scanned is skipped until its files change or Rescan is pressed.
• Rescan reopens every bundle.
• A node whose plugin is gone shows "Not installed, or failed to load".

Why is this the right approach?

This is how DAWs handle large plugin libraries: a persistent plugin list, reopening only bundles that changed, and nodes that don't each trigger their own scan. A bundle counts as changed when the latest mtime or total size of its files changes (skipping Resources), since installers often leave the bundle folder's own mtime unchanged.

The cache is dropped on every app update, so a new release never relies on an older one's scan results.

Possible future improvement (not a priority now): scan plugins in a separate process with a timeout, so the first scan doesn't freeze the UI and a crashing plugin can't take the app down.

Checklist

• Diff is limited to the change
• bun run check passes
• cargo check --manifest-path src-tauri/Cargo.toml passes
• bun run format leaves the tree clean
• Generated TS types are committed with the Rust change (N/A)
• No new dependency
• No changes to the RT audio path

Platform coverage

• Developed on: macOS
• Tested on: macOS, unit tests only (cache reuse, changed/added/removed bundles, full rescan, disk round-trip, release change, failed/panicking/crashing bundles, symlink loops)
• Not tested: manual testing with real plugins; Linux; Windows

No per-OS files are touched.

Related

• Fixes [bug] Pipeline editor hanging with mutiple 'plugin' nodes #60