fix: deterministic DOM widget clip-path for flaky screenshot test (#9400)

## Summary

Fix deterministic DOM widget clip-path rendering to resolve the flaky
"Can drag node" screenshot test.

## Root Cause

`useDomClipping.updateClipPath()` schedules clip-path calculation in a
`requestAnimationFrame`, but `DomWidget.vue`'s watcher reads
`clippingStyle.value` synchronously before the RAF fires. The stale
clip-path gets baked into `style.value` and never updated when the RAF
completes, causing the textarea DOM widget to non-deterministically
render in front of or behind the canvas-drawn node selection border.

## Fix

- Extract `composeStyle()` function and add a dedicated watcher on
`clippingStyle` that recomposes the final inline style whenever the
RAF-deferred clip-path updates
- Add `enableDomClipping` to the main watcher dependency array so
toggling the clipping setting immediately recomposes the style
- Add `moveMouseToEmptyArea()` call in the test as a secondary
stabilizer against hover highlight non-determinism
- Delete stale snapshot so CI regenerates it with correct clip-path
behavior

- Fixes #4658

---------

Co-authored-by: github-actions <github-actions@github.com>

browser_tests/tests/interaction.spec.ts

@@ -171,6 +171,8 @@ test.describe('Node Interaction', () => {
 
   test('Can drag node', { tag: '@screenshot' }, async ({ comfyPage }) => {
     await comfyPage.nodeOps.dragTextEncodeNode2()
+    // Move mouse away to avoid hover highlight on the node at the drop position.
+    await comfyPage.canvasOps.moveMouseToEmptyArea()
     await comfyPage.nextFrame()
     await expect(comfyPage.canvas).toHaveScreenshot('dragged-node1.png')
   })