Prove the cloud MSVC dllimport fix by turning on the Windows shared build

Follow-up from #764 by @ayaangazali -- thanks again for that PR!

What

#764 fixes the MSVC LNK2001: unresolved external symbol g_cloud_stt_ops error by adding dllexport/dllimport decoration (engines/cloud/include/rac/backends/rac_cloud_api.h), but no CI job actually links runanywhere_cloud against the shared rac_backend_cloud.dll on Windows to exercise the dllimport side it adds. CMakePresets.json:352 still sets RAC_BACKEND_CLOUD: OFF for windows-x64-shared-release, core/scripts/build-windows.bat:208-214 still omits runanywhere_cloud from BUILD_TARGETS with a comment saying it "does not link on MSVC," and neither pr-build.yml's DLL assertion nor check_plugin_natives.py's REQUIRED_OPS list a cloud entry.

Why it matters

The fix is unexercised on Windows: the only Windows jobs that compile cloud (cpp-desktop-windows-x64, python-windows) use RAC_STATIC_PLUGINS=ON, which only builds the dllexport branch. A future regression to the dllimport side would ship silently.

Suggested approach

• Flip RAC_BACKEND_CLOUD to ON in the windows-x64-shared-release preset (CMakePresets.json:352).
• Add runanywhere_cloud to BUILD_TARGETS in core/scripts/build-windows.bat and rewrite the now-stale comment at line 208.
• Add rac_backend_cloud.dll / runanywhere_cloud.dll to the windows-commons-release DLL assertion and "cloud": ("g_cloud_stt_ops",) to check_plugin_natives.py's REQUIRED_OPS.

Done when

• A green windows-commons-release run links runanywhere_cloud against the shared rac_backend_cloud.dll on MSVC.

Not blocking #764. @ayaangazali, you know this code well now -- you're welcome to take this one if you're interested.

Opened with help from Claude Code and Codex.

Reviewed with help from Claude Code and Codex.