[RFC] Support using a server-side fallback for browsers without WebAssembly support

[rbtying]

---

Add WebAssembly-optional support with HTTP RPC fallback

Summary

This PR enables the Shengji frontend to run in environments where WebAssembly (WASM) and JavaScript JIT compilation are
not available, such as certain mobile browsers, restricted corporate environments, or older devices. The implementation
provides a seamless fallback mechanism using HTTP RPC calls to the backend when WASM is unavailable.

Problem

Previously, the frontend required WebAssembly support to run game logic locally. This created compatibility issues in:

• iOS browsers with lockdown mode enabled
• Corporate environments with strict security policies
• Older browsers without WASM support
• Devices with JIT compilation disabled

Solution

Implemented a dual-mode architecture where the frontend can operate with either:

1. WASM mode (preferred): Game logic runs client-side for optimal performance
2. RPC mode (fallback): Game logic executes server-side via HTTP endpoints

Key Changes

Architecture

• New EngineContext: Unified interface abstracting WASM and RPC implementations
• Automatic detection: Runtime detection of WASM availability with automatic fallback
• Async conversion: All game engine calls converted from synchronous to async operations

Performance Optimizations

• Batch API for card info: Reduces requests from 55+ individual calls to 1 batch request
• Intelligent caching: Trump-dependent caching for card information and scoring explanations
• Cache prefilling: Proactive cache population at game start to minimize runtime requests
• Request reduction: Backend requests reduced from 100+ to ~60-70 per game session

Backend Additions

• New /api/rpc endpoint handling 10 game engine operations:
  • findValidBids, explainScoring, computeScore, canPlayCards
  • nextThresholdReachable, findValidPlays, findPlayableCards
  • batchGetCardInfo, sortHand
• Shared implementation between WASM and RPC via wasm-rpc-impl crate
• Proper error handling and type safety throughout

Frontend Updates

• All components updated to use async/await patterns
• Loading states added for better UX during async operations
• Removed legacy synchronous WasmProvider
• Maintained backward compatibility with existing WASM mode

Testing

• ✅ Manual testing in WASM mode (existing behavior preserved)
• ✅ Manual testing in RPC mode (via test harness disabling WASM)
• ✅ Cache effectiveness verified (55+ requests → 1 batch)
• ✅ All existing functionality maintained

Performance Impact

• WASM mode: No performance regression
• RPC mode: ~50-100ms latency per operation (acceptable for fallback)
• Caching: Significantly reduces perceived latency in RPC mode

Migration Notes

• No breaking changes for existing users
• Automatic fallback requires no configuration
• Server must be updated to support RPC endpoints

Files Changed

• 30 files changed, 2374 insertions(+), 771 deletions(-)
• Main changes in WasmOrRpcProvider.tsx, wasm_rpc_handler.rs, and component async conversions

Future Improvements

• Consider WebSocket-based RPC for reduced latency
• Add metrics to track WASM vs RPC usage
• Optimize cache invalidation strategies

---

This PR makes Shengji accessible to a wider audience while maintaining the performance benefits of WebAssembly where
available.