Fix webapp issue for Safari browser

[rouzwelt]

Motivation

fixes #2029
fixes #2213

There was an issue with safari browser for webapp that it errors on startup with unintiailized variable, this PR fixes that.

the issue is caused by Safari bug, that it cant handle top-level-await specially when it is imported multiple times in multiple modules., for more read about this:
sveltejs/kit#7805

In order to fix this issue, we need to update SvelteKit to latest version where ClientInit hook feature is available, this hook allows to do some asynchronous task before the web app is loaded and rendered. and we need to remove the top-level-await in orderbook wasm package build script, provide a function initialization of the orderbook wasm module and initialize it in the ClientInit hook.

To fix this, we ended up with workaround/hack solution, which is to make a think wrapper wasm crate that initializes the js_api (or any other big wasm crate) on start using wasm_bindgen(start) attribute, then on the build script for js_api web bindings (this is only on web/esm, no limitation for node/cjs bindings so we don't need to touch that), we need to append a custom fn that initializes the js_api wasm module with a try/catch, first trying sync and if it fails try async. This works because chrome error on wasm sync init when the size is over 8MB, which can be catched and then init async, but on safari the async init doesn't work at all but the sync init succeeds so we never will reach to async init.
On any other browser or environment such as node with ES6, this should work fine because first the sync init is tried.

Using rust profile release flags (created release-wasm custom profile), we were able to reduce the wasm size down to 4.85 MB, which leaves us with plenty of room for more features that might be added in future, although if at any point we hit the 8Mb limit, we can use the wrapper solution in case Safari bug is not resolved by then.

• Note1: Added a simple script to check the wasm artifact size that gets executed on check and build command for orderbook pkg, which will throw an error if we ever hit 8MB limit.

• Note2: using the heavy size optimizations caused WasmEncodedError and WasmEncodedResult ts type bindings to be duplicated in the generated .d.ts, so needed to add a piece of script to dedupe them.

Solution

Checks

By submitting this for review, I'm confirming I've done the following:

• made this PR as small as possible
• unit-tested any new functionality
• linked any relevant issues or PRs
• included screenshots (if this involves a front-end change)

Summary by CodeRabbit

• Chores
  • Restructured the build to per-package CJS/ESM builds with per-package size checks for faster iteration.
  • Optimized WebAssembly compilation using a size-focused release profile to produce smaller artifacts.
  • Simplified dev/build commands for web and desktop app workflows to skip monorepo build steps.
  • Added automated WASM bundle size validation to prevent oversized releases.