fix(book): stream long-running operations over WebSocket

[suainam]

Summary

• route the Web UI confirm-proposal operation through the existing Book WebSocket
• route page compilation through the same streaming transport
• keep the REST endpoints unchanged for CLI and third-party compatibility
• feed streamed operation events into the existing Book progress timeline

Problem

The current Web UI waits on long-running REST requests. Next.js resets those connections after roughly 35-47 seconds while the FastAPI backend continues generating, so the UI reports a false failure and users may retry the same Book operation.

The same failure mode also affects compile-page during slow providers and fallback chains.

Fix

The frontend now opens a short-lived Book WebSocket for each long operation, sends the existing confirm_proposal or compile_page message, streams progress events, and resolves only after the matching result event. Each page compilation gets its own socket, so parallel page generation remains parallel.

Browser authentication continues to use the existing dt_token cookie; credentials are not added to the WebSocket URL.

Verification

• Node regression tests: 161 passed
• ESLint: 0 errors; existing repository warnings unchanged
• Next.js production build: passed
• Exact v1.5.2 backend with only the patched frontend replaced
• confirm_proposal: result received after 41.5 seconds with 9 streamed events
• compile_page: result received after 691.2 seconds with 24 streamed events
• test log audit: 0 REST proxy calls for the affected routes, 0 socket hang ups, 0 ECONNRESET, 0 tracebacks
• production and isolated test containers remained healthy with 0 unexpected restarts

Fixes #607

[suainam]

Human browser smoke test passed on the isolated v1.5.2 test instance. The UI showed no error, streamed visible progress updates, automatically advanced to Confirm Spine, started compilation after confirmation, and the generated chapter opened successfully. This complements the automated Next.js WebSocket acceptance: confirm_proposal completed in 41.5s and compile_page completed in 691.2s with zero socket hang ups or ECONNRESET.

[suainam]

Additional multi-user verification passed after the browser smoke test. Using an enabled non-admin user in the isolated data copy, confirm_proposal completed through the Next.js WebSocket in 43.0s with 10 events, and compile_page completed in 789.0s with 22 events (21 progress events). Both operations exceeded the old HTTP proxy failure window and received their final result frames. The isolated container/data copy was then removed; production remained healthy and unchanged.

[pancacake]

Thanks for your contribution!