Please address the comments from this code review:

## Overall Comments
- In `GlobalEventInput`, the constructor ignores the explicit `pid` parameter when it is non-zero and blindly overwrites `pid_` from `get_window_info`; consider honoring a non-zero `pid` (and only falling back to the window-derived PID when `pid == 0`) and handling the failure case from `get_window_info` more robustly to avoid ending up with `pid_ = -1`.
- The macOS version checks are inconsistent: `MacOSControlUnitMgr::connect` only guards on `macOS 12.3` while `ScreenCaptureKitScreencap::screencap` requires `@available(macOS 14.0, *)`; consider aligning these checks (and the public API documentation) so callers get a clear and correct minimum-version requirement for ScreenCaptureKit-based capture.
- In `Interactor::select_controller`, the recursive call to `select_controller()` when the macOS controller is unsupported could be replaced with an iterative loop to avoid unbounded recursion and to make the control flow easier to follow for repeated invalid selections.

## Individual Comments

### Comment 1
<location> `source/MaaMacOSControlUnit/Screencap/ScreenCaptureKitScreencap.mm:20-29` </location>
<code_context>
+    if (@available(macOS 14.0, *)) {
</code_context>

<issue_to_address>
**issue (bug_risk):** macOS version requirements for ScreenCaptureKit are inconsistent with the manager and will break on 12.3–13.x.

MacOSControlUnitMgr::connect only gates on macOS 12.3+, but ScreenCaptureKitScreencap::screencap is now limited to macOS 14.0+. On 12.3–13.x, connect() will succeed while all screencap calls log an error and return std::nullopt. Please either:
- lower this availability to @available(macOS 12.3, *), or
- raise MacOSControlUnitMgr::connect to 14.0+ and update its error messaging accordingly.
These checks need to stay aligned to avoid this partial, non-functional state.
</issue_to_address>

### Comment 2
<location> `source/MaaMacOSControlUnit/Manager/MacOSControlUnitMgr.cpp:36-45` </location>
<code_context>
+        return false;
+    }
+
+    switch (screencap_method_) {
+    case MaaMacOSScreencapMethod_ScreenCaptureKit:
+        screencap_ = std::make_shared<ScreenCaptureKitScreencap>(window_id_);
+        break;
+
+    default:
+        LogError << "Unknown screencap method: " << static_cast<int>(screencap_method_);
+        break;
+    }
+
+    switch (input_method_) {
+    case MaaMacOSInputMethod_GlobalEvent:
+        input_ = std::make_shared<GlobalEventInput>(window_id_, pid_);
+        break;
+
+    default:
+        LogError << "Unknown input method: " << static_cast<int>(input_method_);
+        break;
+    }
+
+    connected_ = true;
+    return true;
+}
</code_context>

<issue_to_address>
**issue (bug_risk):** connect() reports success even when screencap or input initialization fails.

For unknown screencap_method_ / input_method_, we only log and leave screencap_ / input_ as nullptr, yet still set connected_ = true. Callers then hit runtime failures on nullptr. Consider only setting connected_ when both screencap_ and input_ are non-null, and returning false (or falling back to a default implementation) if creation fails so that "connected" reflects actual readiness for use.
</issue_to_address>

### Comment 3
<location> `source/MaaPiCli/Impl/Configurator.cpp:239-248` </location>
<code_context>
             std::cout << MAA_NS::utf8_to_crt(std::format("\t\t{}\n", format_win32_config(config_.configuration().win32)));
         }
         break;
+    case InterfaceData::Controller::Type::MacOS: {
+        const auto& macos = config_.configuration().macos;
+        std::cout << MAA_NS::utf8_to_crt(std::format(
</code_context>

<issue_to_address>
**suggestion (bug_risk):** Runtime macOS screencap/input methods ignore user-selected values in Configuration::macos.

This code only uses `controller.macos.screencap_method` / `input_method` from `interface.json`, defaulting them only when those strings are empty/invalid. But `Interactor::select_macos` writes the user’s choices into `config_.configuration().macos.screencap_method` / `input_method`, which are never read here, so CLI/config overrides have no effect.

If user overrides are intended, you likely want a clear precedence order between `controller.macos.*` and `configuration().macos.*` (e.g., one falling back to the other when empty) so runtime behavior reflects user edits.
</issue_to_address>

### Comment 4
<location> `source/MaaMacOSControlUnit/Input/GlobalEventInput.mm:222-231` </location>
<code_context>
+    static std::map<char, CGKeyCode> key_map
</code_context>

<issue_to_address>
**issue (bug_risk):** input_text doesn’t correctly handle shifted punctuation and duplicates mapping for upper/lowercase letters.

Currently both cases of a letter map to the same key code and `need_shift` is inferred via `isupper(c)`, which only works for letters. Punctuation like `'!'` and `'@'` are mapped directly to number-row key codes without marking `need_shift`, so `'!'` results in a bare `'1'`.

Please change the mapping to only store base (unshifted) characters and determine Shift separately (e.g., `'!' -> ('1', needs_shift=true)` or via a parallel table). This will fix punctuation input and avoid duplicating A/a … Z/z entries in `key_map`.
</issue_to_address>

### Comment 5
<location> `sample/cpp/main.cpp:172` </location>
<code_context>
+        std::string window_name = MaaToolkitDesktopWindowGetWindowName(window_handle);
+
+        if (window_name.find("关于本机") != std::string::npos) {
+            window_id = reinterpret_cast<uintptr_t>(MaaToolkitDesktopWindowGetHandle(window_handle));
+            break;
+        }
</code_context>

<issue_to_address>
**nitpick (bug_risk):** Potential narrowing when converting the window handle to window_id.

`MaaToolkitDesktopWindowGetHandle` returns a `void*`, which you cast to `uintptr_t` and then store in a `uint32_t`. On 64-bit platforms this is a narrowing conversion and could truncate the handle, even if `CGWindowID` is currently 32-bit. It would be safer to obtain the actual `CGWindowID` when building `DesktopWindow`, or at least cast directly to `uint32_t` here with a clarifying comment that the underlying ID is 32-bit by contract.
</issue_to_address>