Train browser models in a Web Worker

[ale18V]

What & why

Training currently runs on the browser's main thread and can freeze the UI for large models. This moves model training into a Web Worker for local, federated, and decentralized sessions. For decentralized training, WebRTC remains on the page and the worker exchanges serialized model weights with the page at round boundaries. Image loading now works in a worker, and training progress and stop controls continue to update the dashboard. The dashboard regression test retains real Titanic CSV training, computed accuracy, and savable-model checks through the production worker entry, and caught a Vue proxy that could not be cloned into the worker.

Technical plan

The dashboard streams dataset samples to the worker and receives progress and the final model. A client bridge forwards decentralized connection, synchronization, and weight exchange requests to the page. Encoded weights use transferable buffers between threads. A local Chromium integration run against the real signaling server passed with two isolated browser contexts, four decentralized rounds per peer, and both trained models saved. A separate synthetic CPU benchmark of two 64 MiB weight sets measured median main-thread encoding, decoding, and averaging times of 14.6 ms, 23.1 ms, and 637.4 ms respectively (three runs); no main-thread long tasks were observed during the small Titanic training session.

Deviations from plan

None.

Todo

Move decentralized aggregation and large-weight serialization off the main thread to address the measured stalls. A WASM experiment reduced 64 MiB averaging to a median 36.7 ms, but the complete encode/decode/average sequence still took 150.2 ms; this backend change is not included in the PR. The existing full LUS COVID test configuration is restored, but its CPU fallback run did not complete: after more than five minutes it was still on the first training batch, so that validation remains unresolved.