feat: wait on ComfyUI websocket feed instead of polling for completion

Resolves the "async generation" open question from the adapter plan.
generate() now watches ComfyUI's websocket events (executing/progress/
execution_error) and reacts immediately instead of sleeping between REST
polls, with an optional on_progress callback that comfyui_video uses to
print step progress on long renders. websocket-client is an optional
import; _wait() falls back to the original poll() loop (with the
remaining time budget, not a fresh one) when it's unavailable or the
connection drops, so resume_prompt_id recovery is unaffected either way.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/comfyui-adapter-plan.md

@@ -474,9 +474,16 @@ pipeline definition, or any schema.
    user-provided via a config directory? Bundling gives reproducibility;
    external gives flexibility.
 
-2. **Async generation:** ComfyUI supports websocket connections for real-time
-   progress. Worth implementing for long video generations, or is polling
-   sufficient?
+2. ~~**Async generation:**~~ **Resolved.** `ComfyUIClient.generate()` now
+   waits via ComfyUI's websocket feed (`wait_ws()`) by default, reacting to
+   `executing`/`execution_error` events immediately instead of sleeping
+   between REST polls — completion and errors are caught without the
+   `interval`-seconds lag, and an optional `on_progress` callback gets live
+   `progress` events (`comfyui_video` uses this to print step progress on
+   long renders). No new hard dependency: `websocket-client` is an optional
+   import, and `_wait()` transparently falls back to the original
+   `poll()` REST loop when it isn't installed or the connection fails —
+   `resume_prompt_id` recovery behaves identically either way.
 
 3. **Multi-server:** Should the adapter support multiple ComfyUI instances
    (e.g., one for images, one for video) via per-capability URLs?