#3889 fix(macos): open a running app by its own path instead of its bundle id

Summary

open <bundleId> --platform macos could start a second, argument-less copy of a running app. open -b opens the registered copy LaunchServices resolves the bundle id to. When an earlier build of the bundle is still registered at another path, such as a previous dev build, open -b launched that stale copy beside the running one, and the session drove it.

When exactly one listed copy runs, the open now runs open [-g] <its path> (-a <path> <url> for a link). It keeps open -b when:

• no copy runs;
• a copy is still unlisted after the #3707 wait;
• copies run from more than one path;
• the executable path is not absolute, since a relative argv[0] names no bundle here (macAppBundlePath is the only producer of the path).

5 files, including website/docs/docs/commands.md. Related: #3406.

Validation

Head 583b866df, base c8b944ca0.

• pnpm check:affected --base upstream/main --head 583b866df --run: all runnable checks passed, exactCommit: true. (One earlier run hit load timeouts in unrelated provider-integration files; rerun clean.) Coverage and macOS smoke run on GitHub.
• Live at 3b17a4b73, macOS 27, a running app at path B with an older build registered at path A:
  • Base: a second, argument-less process from path A.
  • Head: one process, also after a second open and for a copy spawned directly and opened 0 to 3 s later.
• Not run live: the case-insensitive compare and the absolute-path check, added after 3b17a4b73.
• Risk: opening a running app adds one ps and one plutil read, inside the 2.5 s probe budget.