Please address the comments from this code review:

## Overall Comments
- Several state flags used across threads (e.g., `mouse_lock_follow_active_`, `tracking_thread_started_for_lock_follow_`, and the `rawinput_ensure_*` booleans) are plain `bool` and read/written from different threads (tracking thread, action runner, destructor); consider making them `std::atomic<bool>` or consistently guarding all accesses with `tracking_state_mutex_` to avoid data races.
- The tracking thread now calls `SetProcessDpiAwarenessContext` / `SetProcessDpiAwareness` every time it starts; this alters DPI awareness process-wide and may surprise host applications—if possible, centralize this as a one-time initialization (or behind a config/feature flag) rather than doing it in a per-controller tracking thread.
- The lifetime coupling between `MessageInput`, `tracking_thread_func`, and the RawInput message window relies on `tracking_exit_` plus `destroy_rawinput_window()` in the tracking thread; double‑check that all destruction paths (including error cases and `inactive()`) ultimately join the tracking thread before `MessageInput` is destroyed, otherwise the static `RawInputWndProc` may see a dangling `s_active_instance_` target.

## Individual Comments

### Comment 1
<location path="source/MaaWin32ControlUnit/Input/MessageInput.cpp" line_range="491-496" />
<code_context>
+                // 如果失败可能是已经设置过（E_ACCESSDENIED），这是可以接受的
+            }
+        }
+        if (!ok) {
+            HMODULE shcore = LoadLibraryW(L"shcore.dll");
+            if (shcore) {
+                using FnAware = HRESULT(WINAPI*)(int);
+                auto fnAware = reinterpret_cast<FnAware>(GetProcAddress(shcore, "SetProcessDpiAwareness"));
+                if (fnAware) {
+                    fnAware(2 /*PROCESS_PER_MONITOR_DPI_AWARE*/);
+                }
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Consider freeing the shcore.dll module handle after using SetProcessDpiAwareness.

`LoadLibraryW(L"shcore.dll")` is called here but the returned `HMODULE` is never released. Since `tracking_thread_func` may run multiple times, this can cause a small, repeated resource leak. Please call `FreeLibrary(shcore);` after `SetProcessDpiAwareness` has been invoked (or attempted).
</issue_to_address>

### Comment 2
<location path="source/MaaWin32ControlUnit/Input/MessageInput.cpp" line_range="508-517" />
<code_context>
     timeBeginPeriod(1);
-    OnScopeLeave([this]() {
+    bool init_reported = false;
+    OnScopeLeave([&]() {
+        {
+            std::lock_guard lock(tracking_state_mutex_);
+            if (!init_reported) {
+                tracking_thread_init_done_ = true;
+                tracking_thread_init_ok_ = false;
+            }
+            rawinput_ensure_requested_ = false;
+            rawinput_ensure_done_ = true;
+            rawinput_ensure_ok_ = false;
+        }
+        tracking_state_cv_.notify_all();
         close_target_process();
+        destroy_rawinput_window();
         timeEndPeriod(1);
     });

</code_context>
<issue_to_address>
**nitpick:** Using a by-reference capture in the scope guard risks capturing more than necessary.

The `OnScopeLeave([&] { ... })` in `tracking_thread_func` captures all locals by reference, though only `this` and `init_reported` are needed. Please switch to an explicit capture list (e.g. `[this, &init_reported]`) to clarify lifetimes and avoid accidental future use of other locals by reference in this lambda.
</issue_to_address>