Repository: godot
Issue: Second instances of running exported macOS projects do not get opened file paths in launch arguments
Labels: bug,platform:macos,topic:porting

### Tested versions

Reproducible in 4.3bX and 4.3rc1

### System information

macOS 14.5

### Issue description

When launching an exported Godot project by opening a file in the OS (or dragging it onto the Dock/taskbar icon of the application) you can access this file path as the first launch argument in `OS.get_cmdline_args()`. There is currently no other way to get access to files passed from the OS as discussed in https://github.com/godotengine/godot-proposals/issues/10195 . If the process is already running when the file is sent from the OS, the current implementation is to start a new duplicate process and pass the file path as a launch argument for that. 

This works as expected on Windows, but not on macOS:
- While the first process launched on macOS does get the file path launch argument, the following duplicate processes launched do not get the passed file path as a launch argument. So opening a second file while the process is running results in a copy of the process being started but the opened file not being opened. 
- Second there is the underlying issue that it's sometimes not desirable to launch a second duplicate process (On Windows and Linux perhaps a matter of preference, on macOS I'd consider it a bug) for that see https://github.com/godotengine/godot-proposals/issues/10208 . If this was resolved and such a single-instance mode was the default on macOS this launch argument issue would not be a problem if the path was instead sent to the running process in some way. 


### Steps to reproduce

- Set up a new project that just at start grabs the launch arguments
`var arguments:PackedStringArray = OS.get_cmdline_args()`
And displays these in a label or prints them out.
- Export this project to macOS (this may require you supply code signing details, but I'm not sure)
- In the macOS file system, pick a file (like a simple text file) and in the Get info dialogue configure it manually to be opened by your exported project application.
- Double click the file and observer the application being launched and the `arguments` printed out containing the path to the file.
- Double click the file again (or another associated with your exported application) and observe a new copy of the a application being launched but with the output `arguments` being empty.

If you want to be more advanced you can add something like this:
```
<key>CFBundleDocumentTypes</key>
<array>
<dict>
<key>CFBundleTypeRole</key>
<string>Editor</string>
<key>LSItemContentTypes</key>
<array>
<string>public.text</string>
</array>
</dict>
</array>
```
In the Additional Plist Content field of your macOS export, which should enable your exported application to open .txt files from macOS with it once it's installed. 

### Minimal reproduction project (MRP)

Since this is related to exported builds and exporting (at least successfully) to macOS requires inputting personal codesigning details I don't want to submit a MRP. But the steps to reproduce above should hopefully be minimal enough to be easy to reproduce.