In comment mode, clicking a node opens the node settings panel, bypassing the comment-mode guard

### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.16.0 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce 1. Open a workflow on a self-hosted instance with collaboration/comments enabled. 2. Switch the canvas to **Comment mode** (the comment cursor appears). 3. Click a node. 4. Observe which surfaces open. ### ✔️ Expected Behavior In comment mode, clicking a node should let me place a comment **without** opening the node **settings** panel. This is already the codebase's intended behaviour for the main node-click path: `handleNodeClick` in `web/app/components/workflow/hooks/use-nodes-interactions.ts` early-returns in comment mode — ```ts // use-nodes-interactions.ts:482-483 const { controlMode } = workflowStore.getState() if (controlMode === ControlMode.Comment) return ``` — so node selection, and therefore the settings panel, is deliberately suppressed while commenting. I expect clicking a node in comment mode to behave consistently with that decision. ### ❌ Actual Behavior Clicking a node in comment mode opens the node **settings** panel. The node's title/header is one path that does this: its click handler bypasses the comment-mode guard that `handleNodeClick` applies. ```tsx // web/app/components/workflow/nodes/_base/node.tsx:243 onClick={() => selectWorkflowNode(id)} // no comment-mode guard ``` `selectWorkflowNode` dispatches the `workflow:select-node` event → `handleNodeSelect` sets `data.selected = true` (`use-nodes-interactions.ts:443-476`), and the right-hand settings panel renders (`panel/index.tsx:85` selects on `node.data.selected`). **The core defect is the inconsistency:** the project already decided node clicks should not select in comment mode (the guard in `handleNodeClick`), but this path does not honour that decision. **User-visible consequence (conditional):** the settings panel is a fixed right-hand panel (`panel/index.tsx:134`, `absolute ... right-0`, ≥400px). When the node being annotated sits under that strip, the panel covers the canvas region where the comment anchor is placed, so you can't see what you're annotating while you type. There is also some secondary UX friction (the panel has to be dismissed before placing another comment; a single action ends up split across three surfaces), but I'd treat those as separate UX considerations, not part of this bug — the bug is the guard inconsistency above. A short screen recording is attached, since the problem is about the sequence and occlusion of surfaces, which a still can't convey. **Before** — comment mode, clicking a node opens the node settings panel over the canvas. https://github.com/user-attachments/assets/271568df-7f6b-48d3-a979-de9d07d842a3