bin/org-capture introduces significant delay (MacOS)

### I confirm that...

- [X] I have searched the [issue tracker](https://github.com/doomemacs/doomemacs/issues), [documentation](https://docs.doomemacs.org), [FAQ](https://docs.doomemacs.org/-/faq), [Discourse](https://discourse.doomemacs.org), and [Google](https://google.com), in case this issue has already been reported/resolved.

- [X] I have read "[How to Debug Issues](https://doomemacs.org/d/how2debug)", and will use it to provide as much information about this issue as possible.

- [X] The issue can be reproduced on the **latest** available commit of Doom.

- [X] The issue can be reproduced on a stable release of Emacs, such as 27, 28, or 29. *(Unstable versions end in .50, .60, or .9x)*

### Expected behavior

bin/org-capture is most useful for capturing notes/tasks when working outside of Emacs by quickly spawning a new frame to collect a task/note.

### Current behavior

When calling `bin/org-capture` (and hence `+org-capture/open-frame`) a 2+ second delay exists between command start and a usable Emacs frame starting. I was able to track down the delay in `+org-capture/open-frame` to this line.
https://github.com/doomemacs/doomemacs/blob/9620bb45ac4cd7b0274c497b2d9d93c4ad9364ee/modules/lang/org/autoload/org-capture.el#L54

I haven't tried to go any further with a root cause yet because I'm fine with a redefinition of `+org-capture/open-frame` in my local config. Here it is for reference:
```elisp
;; Redefine to remove delay startup bug
(defun +org-capture/open-frame (&optional initial-input key)
"Opens the org-capture window in a floating frame that cleans itself up once
you're done. This can be called from an external shell script."
(interactive)
(when (and initial-input (string-empty-p initial-input))
(setq initial-input nil))
(when (and key (string-empty-p key))
(setq key nil))
(let* ((frame-title-format "")
(frame (if (+org-capture-frame-p)
(selected-frame)
(make-frame +org-capture-frame-parameters))))
;; BUG: Causes significant delay on startup
;; (select-frame-set-input-focus frame) ; fix MacOS not focusing new frames
(with-selected-frame frame
(require 'org-capture)
(condition-case ex
(letf! ((#'pop-to-buffer #'switch-to-buffer))
(switch-to-buffer (doom-fallback-buffer))
(let ((org-capture-initial initial-input)
org-capture-entry)
(when (and key (not (string-empty-p key)))
(setq org-capture-entry (org-capture-select-template key)))
(funcall +org-capture-fn)))
('error
(message "org-capture: %s" (error-message-string ex))
(delete-frame frame))))))
```
After using the above redefinition in my personal config `bin/org-capture` yields a usable frame almost instantly. Of course now the frame isn't focused automatically. On MacOS I use Yabai as my window manager which allows me to write a very simple signal action to solve this issue in my `.yabairc`
```
yabai -m signal --add event="window_created" app="^Emacs$" label="doom-capture-focus" title="^doom-capture$" action="yabai -m window --focus \$YABAI_WINDOW_ID"
```

Sorry if this issue seems trivial or pedantic. The lag was bothering me because I use org-capture a lot and just wanted to report my findings incase it's helpful to anyone.

### Steps to reproduce

1. Observe time: $ `bin/org-capture` -> interactive Emacs frame (2+ seconds)
2. Redefine `+org-capture/open-frame` in `config.el` with above snippet.
3. Observe new time: $ `bin/org-capture` -> interactive Emacs frame (< 1 second)

### System Information

https://pastebin.com/FfXJHFHP

Start with bin/org-capture and modules/lang/org/autoload/org-capture.el, especially the linked line in +org-capture/open-frame. Reproduce the delay on macOS, compare behavior with select-frame-set-input-focus disabled, and inspect the provided redefinition. Done means the capture frame opens promptly while retaining appropriate focus behavior.

Written by the indexing model from the issue text.