Fix WASM binding resolution across module scopes

[Arnold-Seb]

Summary

Generated C# WASM bindings were failing to load and initialise correctly at runtime. The lookup in CSharpWasmExpo/main.js that resolves each binding method against the WASM module scope only checked a single naming pattern, so methods exposed under a different scope or naming convention (e.g. __sklib_-prefixed keys) were silently missed.

Change

Updated the binding resolution logic in CSharpWasmExpo/main.js to fall back through multiple lookup strategies when resolving a binding function:

1. globalThis[name]
2. wasmScope[name]
3. wasmScope["_CPP_" + name]
4. A wasmScope key that starts with __sklib_ and matches the target name

This mirrors how the underlying SplashKit bindings are actually exposed across the different generated/module scopes, rather than assuming a single fixed pattern.

Testing

• Re-tested binding loading across the CSharpWasm and CSharpWasmExpo projects to confirm bindings now resolve and initialise correctly.
• Exercised edge-case scenarios (bindings exposed under the __sklib_ prefix and via the iframe-scoped wasmScope) to confirm the fallback resolves them without regressing previously-working lookups.

Scope

This PR only touches CSharpWasmExpo/main.js. No build artifacts or generated files are included.

[jankiluitel]

Reviewed the changes and the updated binding resolution approach looks good. The fallback handling across different module scopes improves robustness while keeping the change focused. The implementation is clear and the existing checks are passing. Approved from my side. ✅