Improve search workflows, large-result sorting, and usability

[MehmetEminBozdag]

Summary

• keep large-result metadata sorting responsive with cancellation and latest-request backpressure
• reduce background CPU work and avoid waiting on cache flushes during Cmd+Q shutdown
• add validated in-app Move to Trash with operation feedback, including a fix for macOS native-menu confirmation timing
• expose plain-language search filters, newest-first sorting, folders as a type, and workspace foundations
• localize the added UI across all 15 supported locales

Scope clarification

This PR does not change the speed of core query matching. The performance work here is limited to sorting large metadata result sets, cancellation, and preventing stale requests from piling up. The filters and saved-search UI are workflow improvements intended to help users reach the right file with fewer steps.

Verification

• frontend: 37 test files, 323 tests passed
• targeted selection/context-menu regression: 3 test files, 61 tests passed
• TypeScript: npm run typecheck passed
• production frontend: npm run build passed
• Rust: 49 tests passed
• Rust lint: cargo clippy --all-targets -- -D warnings passed
• whitespace: git diff --check passed

The original Move to Trash failure was reproduced in the packaged macOS app. The timing fix is covered by a regression test and packaged successfully; the post-fix destructive UI rerun is still pending Full Disk Access re-approval for the new app signature.

Follow-up stack

This is PR 1 of 3. The prepared follow-ups cover workspace/menu/coverage controls, then APFS-aware duplicate analysis. They remain separate so each review can focus on one incremental area.

[ldm0]

Thank you for your efforts, but this PR does not appear to improve search performance?

[MehmetEminBozdag]

Thanks, that's fair. I used "search performance" to mean the overall search workflow. Filters, saved searches, newest-first sorting, and the UI changes are meant to help users find a file faster. But you're right that this PR doesn't make the core search engine itself faster. The actual performance work is mostly around sorting large result sets.
I've renamed the PR to "Improve search workflows, large-result sorting, and usability." I can also split the sorting changes from the UI changes if that would make the PR easier to review.

[MehmetEminBozdag]

Small update: I fixed a macOS issue where “Move to Trash” could silently do nothing because the confirmation was opened before the native context menu had closed. I also updated the PR description to make the scope clearer: this does not speed up core query matching; the performance changes are in large-result sorting, cancellation, and request backpressure. The frontend suite now passes 323 tests.