#22350 cmux NEXT Files: open and reveal off the main thread (base check-concurrency red)

cmux-next checks (check-concurrency) is red on feat-cmux-next since the Files pane slice landed:

concurrency: Sources/CmuxNextFilesUI/FilesPaneView+Actions.swift:90: synchronous NSWorkspace open or reveal (cx-050n)
concurrency: Sources/CmuxNextApp/FilesPane/FilesPaneService.swift:118: synchronous NSWorkspace open or reveal (cx-050n)

Both calls now go through CmuxNextCompat's openInBackground / revealInBackground, like every other CmuxNext open. FilesUI already depends on CmuxNextCompat; the file gains the import.

Why it matters: when cmux-next checks fails, the cmux-next fast tier job is cancelled, so gh-merge-green refuses every feat-cmux-next PR (seen on #21447 and #22097).

FYI @lawrencecchen: this touches your Files pane only at these two calls.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

Fixes the cmux-next checks (check-concurrency) failure on feat-cmux-next by moving the Files pane's NSWorkspace open and reveal calls off the main thread.

Both calls now use CmuxNextCompat's openInBackground / revealInBackground, matching how every other CmuxNext open works. When this check fails, the cmux-next fast tier job is cancelled, which makes gh-merge-green refuse every feat-cmux-next PR.