useSlotElementTracking: unbounded RAF retry loop when canvas unavailable during collapsed-node slot sync

## Summary

In `src/renderer/extensions/vueNodes/composables/useSlotElementTracking.ts`, the `syncNodeSlotLayoutsFromDOM` function introduced in PR #10641 contains a potential unbounded retry loop.

## Problem

When a node is collapsed and `canvasStore.canvas` is `null` (i.e., `conv` is `null`), the code calls `scheduleSlotLayoutSync(nodeId)` and returns early:

```ts
if (isCollapsed && !conv) {
scheduleSlotLayoutSync(nodeId)
return
}
```

`scheduleSlotLayoutSync` re-queues the node via a RAF batch, which will call `syncNodeSlotLayoutsFromDOM` again on the next animation frame. If `canvasStore.canvas` never becomes truthy (e.g., during a teardown race or after an initialization error), this creates a **60fps busy loop** with no backoff or max-retry limit.

In practice the canvas initializes early and collapsed nodes cannot exist pre-canvas (making the race unlikely), but there is no guard preventing infinite retries in edge cases.

## Suggested Fix

Consider one or more of:
- Adding a **bounded retry count** (e.g., drop the node after N failed attempts and log a warning).
- Adding a **code comment** explicitly documenting the safety assumption: collapsed nodes require an initialized canvas; if canvas is null here it will be available on the next frame since collapse is user-initiated.
- Listening for a canvas-ready event/reactive signal to flush deferred nodes instead of polling via RAF.

## References

- PR introducing the code: #10641
- Review comment: https://github.com/Comfy-Org/ComfyUI_frontend/pull/10641#discussion_r3011997734
- Reported by: @DrJKL

┆Issue is synchronized with this [Notion page](https://www.notion.so/Issue-10794-useSlotElementTracking-unbounded-RAF-retry-loop-when-canvas-unavailable-during-colla-3356d73d365081899ee5c1f70d53c365) by [Unito](https://www.unito.io)