fix(electron): open Lody on Windows tray left click

[lodystage]

Author type

• I am an Agent (check this if an LLM agent authored this PR)
• I am a human

Problem / pressure

On Windows, left-clicking the tray icon behaved exactly like right-clicking: it popped up the context menu instead of opening the app. That is contrary to the platform convention, so the common action (show Lody) cost an extra click and an extra decision.

Summary

WindowsTrayService's click handler called this.tray.popUpContextMenu(). It now calls openOrFocusMainWindow() — the same callback the tray menu's "Open Lody" item already uses. setContextMenu is untouched, so the menu still opens on right click (on Windows that call only binds the right-click gesture, which is why the explicit popUpContextMenu() existed in the first place).

Before / after

Before	After
Left click on tray icon → context menu	Left click on tray icon → main window opens/focuses
Right click on tray icon → context menu	Right click on tray icon → context menu (unchanged)

Test plan

• No automated checks were run: this worktree has no node_modules, so pnpm check / tsgo are unavailable here. CI covers type/lint/test.
• Not manually verified on Windows — no Windows host available in this environment.
• Static reasoning: the new call is identical to the existing Open ${productName} menu item's handler in the same file, so no new API surface or types are introduced.

Agent handoff

Instructions for reviewing agents

• Review focus: apps/electron/src/main/services/windows-tray-service.ts — the single tray.on('click') handler; confirm setContextMenu still yields right-click menu behavior on your target Windows/Electron version.
• Decisions to challenge: Keeping setContextMenu rather than binding right-click → popUpContextMenu() explicitly; also whether left click should toggle (hide when already focused) instead of always opening/focusing.
• Plausible failures / evidence gaps: Unverified on real Windows; if a future Electron version makes setContextMenu also intercept left click, this handler would never fire and the change would silently regress to the old behavior.

Authoring context

• User goal / directives: Make the Windows system-tray icon open Lody directly on left click instead of showing the context menu like right click does.
• Constraints / non-goals: Keep the right-click context menu and its items as-is; no other tray, window, or platform behavior in scope.
• Risk-bearing decisions: None affecting data, authority, compatibility, or recovery — the change is a UI gesture binding in the Windows-only tray service.
• Destructive or irreversible behavior: None.
• Deliberately not done or tested: Repo checks were not run (no node_modules in this worktree) and there was no Windows host for a manual click test; both are stated in the test plan rather than papered over.
• Unknowns / confidence: High confidence in the code change itself; the residual unknown is empirical Windows click behavior, which CI cannot cover either.

Sharing consent (author side)

Declining context sharing is respected, but it does not guarantee review. If withheld context prevents maintainers from assessing provenance, scope, or risk, they may decline the contribution or close the pull request.

• Author-side user explicitly allowed publishing the Authoring context above
• Author-side user explicitly declined publishing Authoring context and understands that maintainers may decline or close the contribution; keep every field as N/A / redacted

🤖 Generated with Claude Code