[Ocean572]

Shell: Rebuild Search Helper Launch Arguments When Folders Change (#199)

Closes #170.

Problem

The shell originally built the search helper's launch arguments once during setup and reused them every time the helper started.

When a folder was added during an active session, the running helper received the update through the live folders request, so searches worked as expected. However, if the helper exited automatically (for example, due to inactivity) and the shell restarted it, the original launch arguments were reused.

This caused the newly added folder to disappear from the helper's configuration. As a result:

• Files in the newly added folder were no longer included in search results.
• The Settings interface continued to display the folder, but its indexing status became incorrect.
• The X of Y indexed count no longer reflected the actual indexing state.

Changes

This PR changes the search helper's launch arguments from a static list into a factory function, search_arguments(), allowing them to be rebuilt using the current application state.

The current launch configuration is now maintained by SearchService through:

• launch: Mutex<Launch> — protects the current launch configuration.
• set_launch_args — updates the saved launch arguments.

Two operations now rebuild the saved arguments whenever the folder configuration changes:

• apply_folders — updates the saved launch arguments whenever folders are added, removed, or modified, before sending the corresponding live request to the running helper.
• turn_off_code — updates the saved arguments when code indexing is disabled, ensuring that a subsequently restarted helper does not reopen the code index.

This keeps the saved launch configuration synchronized with the current Settings state. Any subsequent helper restart now uses the latest folder configuration, including exclusions and code-index settings.

Concurrency and Process Startup

A related issue was identified during pre-push code review.

Previously, start() chained launch.lock().unwrap().clone() directly into .spawn(). Because a MutexGuard remains alive until the end of its statement, this meant the launch mutex was held throughout process creation.

On Windows, antivirus scanning can make process creation take hundreds of milliseconds. Holding the mutex during this operation could therefore block set_launch_args() while a new helper process was starting.

The implementation now takes a snapshot of the launch configuration into a separate let binding before spawning the process.

This provides two important guarantees:

• The launch mutex is released before process creation begins, allowing configuration updates to proceed without waiting for fork/exec.
• The configuration swap remains atomic. A newly spawned helper receives either the complete previous argument list or the complete updated argument list, never a partially updated configuration.

Testing and Verification

Measured on the development machine:

Hardware and environment: Apple M1, 8 GB RAM, macOS 26.5.1.

Rust Tests

• cargo test: 15 tests passed.
• Includes two new unit tests verifying that the rebuilt launch arguments:
  • Include the current folders and their exclusions.
  • Include configured code folders and the index flag.
  • Omit the index flag when no code folders are configured.

End-to-End Verification

Tested against the Swift search helper.

The test started with one indexed root and then expanded the folder configuration to three roots through op:folders.

Two restart scenarios were compared:

Scenario	Indexing result
Restart using the original startup arguments	Only root1 was indexed
Restart using rebuilt launch arguments	All three roots were indexed

The rebuilt configuration successfully restored the expected indexing state:

root1:2, root2:1, root3:1

This reproduces the original issue and verifies that rebuilding the launch arguments resolves it.

Additional Test Suites

• Swift test suite: 125 tests passed (no Swift changes in this PR).
• Shell JavaScript tests: node --test — 17 tests passed.

Scope and Limitations

Windows GUI acceptance testing remains outstanding.

The development environment validates the shell's Rust unit tests but does not run the Tauri GUI application. Windows 11 GUI acceptance testing remains the responsibility of the reporter or maintainer.

Adjacent environment-variable behavior is unchanged and out of scope.

The saved launch environment currently carries DIGUP_MODELS but does not include DIGUP_DEVICE.

set_processor_only relies on this behavior for the index helper, which rebuilds its environment independently. The search helper had the same behavior before this PR, and this change does not modify it.