Do not spam events when the Engine gives a lot of updates

[TurtleOrangina]

Fixes #530

Directly in the rust code that parses the Engine suggestions:

• We let the engine think for 200ms before we forward the latest move analysis info. Rational: Its nice to see something quickly, but the initial updates are very fast (e.g. depth 1-5). We will have a much better evaluation after 200ms than we would have if we just took the first (depth 1) evaluation.
• Once we have forwarded a move suggestion, we buffer suggestions that come within a 500ms window. Suggestions coming in 500ms - 1000ms after the last update are forwarded directly. Once we surpass 1000ms we forward the last buffered suggestion, if we have one. Rational: A human has no benefit from trying to read analysis/lines that are updating much faster. But if the engine is stuck and no longer provided any updates, we want to show the best update so far after a while, and not "hang" on a outdated evaluation forever.

Example (engine pondering for some position):

0ms: Buffering for depth 1
0ms: Buffering for depth 2
1ms: Buffering for depth 3
1ms: Buffering for depth 4
1ms: Buffering for depth 5
3ms: Buffering for depth 6
211ms: Sending after delay for depth 6
307ms: Buffering for depth 13 // the engine didn't send us infos for depths 7-12, but jumps foward to 13
464ms: Buffering for depth 14
700ms: Buffering for depth 15
1030ms: Sending instantly for depth 16
1481ms: Buffering for depth 17
2045ms: Sending after delay for depth 17 // since depth 18 took too long, we sent the buffered depth 17 afterall
2365ms: Buffering for depth 18
2969ms: Sending instantly for depth 19
3615ms: Sending instantly for depth 20
...

[AlieeLinux]

great pull request.. plss add this

[DarrellThomas]

Worth noting: this PR and PR##725 are solving different sides of the same problem. Think of it like drinking from a firehose.

This PR #532 (@TurtleOrangina's fix) turns down the water pressure — it reduces the frequency of events by buffering on the Rust side. Instead of blasting the UI with every depth update (especially the garbage depths 1–5 in the first 200ms), it holds back and only sends updates the human can actually read.

PR#725 (#725) swallows faster — it reduces the cost of each engine event hitting the UI. Before, every event triggered O(N) selector evaluations across all notation cells. Now the parent subscribes once and passes cheap props down. Each gulp is cheap instead of choking.

Either fix alone helps significantly. Together they're belt-and-suspenders — the UI receives fewer events AND each event costs less to process. The two PRs touch completely different files (Rust backend vs React frontend) so they merge cleanly with no conflicts.

I've implemented both in my fork and the result is noticeably smoother than either fix alone.