fix(desktop): reveal .app bundles in Finder instead of launching them - #1625

What Changed

On macOS, "Reveal in Finder" and "Open in Finder" now reveal a .app bundle in its parent folder instead of launching it. Other platforms are unchanged.

• packages/shared/src/filesystemPlatform.ts gets isMacAppBundlePath, which is true for a path ending in .app (any case) on macOS.
• The desktop showInFolder handler's open-or-reveal choice moves into apps/desktop/src/showInFileManager.ts. A .app directory now goes to shell.showItemInFolder like a file. Other folders still go to shell.openPath, and its error handling is unchanged.
• apps/server/src/open.ts passes -R to open for a .app directory in the file-manager path, the same way it already does for files.

Why

A macOS app bundle is a directory, so both paths treated it as a folder to open. Opening a runnable .app directory launches the app. Right-clicking a chat chip such as /Users/me/proj/dist/mac-arm64/MyApp.app and choosing "Reveal in Finder" calls shell.openPath on it, which starts the app instead of showing it. The Finder entry in the "Open in" menu does the same through the server, because open <dir> launches a bundle like a double-click.

Only .app is treated as a bundle. A rule based on any extension would change plain folders such as next.js, v1.2 or example.com, which repos often use as names, from opening to revealing in their parent. Other package types such as .xcodeproj and .bundle keep their current behavior. They are not covered here and could be handled in a separate change.

#1137 is open and also moves this desktop handler into apps/desktop/src/showInFileManager.ts, with a test file of the same name. This change adds files at the same two paths, so whichever lands second will have to merge them by hand, along with the showInFolder hunk in main.ts. #1137 still calls shell.openPath for every directory, so the bundle check would go into its function if it lands first.

UI Changes

No visual change to Synara. The screenshots use the sidebar's "Open in Finder" on a test bundle added as a project, because getting a .app path to render as a chat chip needs a model reply. Both actions go through the same desktop handler. The test bundle only appends a line to LAUNCHED.marker each time it starts. The server path through the "Open in" menu was not run in the app.

Before, "Open in Finder" launched the bundle. The marker went from 0 to 1 line, and Finder did not select it.

After, Finder opened the parent folder with the bundle selected, and the marker stayed at 1 line.

A plain folder named next.js still opens in Finder on both builds.

Verification

• bun run --cwd apps/desktop test -- src/showInFileManager.test.ts: 3 passed. With the base dispatch the .app case fails, because showItemInFolder is never called. With an any-extension rule the next.js case fails, because openPath is never called.
• bun run --cwd apps/server test -- src/open.test.ts: 18 passed. On main the new case fails, because the bundle gets no -R.
• bun run --cwd packages/shared test -- src/filesystemPlatform.test.ts: 5 passed. On main the new case fails, since the helper does not exist yet.
• bun run fmt:check, bun run lint (no new warnings), bun run typecheck and bun run windows-runtime:check pass.
• On this Mac, with a test bundle that appends a line each time it starts, Electron 43's shell.openPath and open <bundle> each launched it, and open -R <bundle> and showItemInFolder did not.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes