feat: Implement Qwen adapter and enhance AI platform detection

- Added a new Qwen adapter to facilitate monitoring through Playwright, leveraging internal text/chat managers.
- Updated account detection logic to recognize Qwen sessions based on persisted cookies, improving binding reliability.
- Relaxed authentication requirements for monitor tasks, allowing anonymous execution for certain AI platforms.
- Enhanced the generic AI platform detection to include Qwen-specific logic, ensuring accurate session identification.
- Modified the monitoring dashboard to include runtime state indicating if the current user's desktop client is online.
- Updated various files including `account-binder.ts`, `runtime-controller.ts`, and `monitoring_service.go` to support new features and improvements.

task_plan.md

@@ -4,7 +4,7 @@
 Continue the desktop AI monitoring implementation by first adding a client-side local scheduler with durable queueing and adaptive execution policy, then adding a reusable hidden Playwright CDP execution layer that attaches to Electron Chromium and reuses existing account partitions.
 
 ## Current Phase
-Phase 17
+Phase 20
 
 ## Phases
 ### Phase 1: Progress Verification
@@ -114,6 +114,26 @@ Phase 17
 - [ ] Summarize what is production-ready versus still scaffolded
 - **Status:** in_progress
 
+### Phase 18: Qwen Adapter & Auth Relaxation
+- [x] Port the browser-extension `qwen` monitor logic into a desktop Playwright adapter
+- [x] Register the new adapter in the desktop runtime monitor execution path
+- [x] Relax Qwen binding completion so the auth window can close once a real session footprint is present
+- [x] Allow anonymous-capable AI monitor platforms to execute without preflight auth blocking
+- **Status:** complete
+
+### Phase 19: Qwen Verification & Delivery
+- [x] Run targeted desktop type/build verification after the Qwen adapter and auth updates
+- [x] Update planning files with the Qwen implementation details and access-policy decision
+- [x] Deliver the completed slice and remaining validation gaps
+- **Status:** complete
+
+### Phase 20: Tracking Collect-Now Repair
+- [x] Audit the `admin-web` tracking collect-now flow against the current desktop monitoring architecture
+- [x] Remove the obsolete browser-plugin kickoff dependency from `TrackingView`
+- [x] Enforce the current logged-in user's desktop client online requirement in both frontend gating and backend collect-now validation
+- [x] Run targeted frontend/backend verification for the repaired flow
+- **Status:** complete
+
 ## Key Questions
 1. How should the desktop client defer and locally optimize monitor-task execution without violating one-task-per-platform serialism?
 2. What is the smallest durable local cache that allows same-day resume while safely dropping stale next-day monitor tasks?
@@ -138,6 +158,7 @@ Phase 17
 | Move scheduling authority fully into `desktop-client` | The user explicitly wants the server to dispatch tasks while the client decides when to execute them |
 | Allow stale cross-day monitor tasks to be dropped on the client | The user explicitly allows漏采 and does not want next-day catch-up for unfinished tasks |
 | Implement hidden browser infrastructure before expanding more adapters | Qwen and similar platforms cannot reliably use direct API calls and need browser-native execution |
+| Only require active login for monitor tasks on `yuanbao` / `kimi` / `deepseek` | The user clarified that other AI platforms can still query and collect anonymously |
 
 ## Errors Encountered
 | Error | Attempt | Resolution |