Add support to Mac when using .NET 10

Problem

SpacetimeDB currently supports the following C# module build paths:

• .NET 8 with wasi-experimental, supported on Windows, Linux, and macOS.
• .NET 10 with NativeAOT-LLVM, supported on Windows and Linux only.

.NET 8 reaches end of support on November 10, 2026. After that date, macOS users building C# modules will be left behind using a .NET version that no longer receives support.

The docs currently state that .NET 10 is unsupported on macOS and recommend using a Linux VM or container as a workaround. We can improve this experience.

Options

1. Build NativeAOT-LLVM binaries for macOS ourselves

This is likely the worst option. It is not trivial, and other projects that depend on NativeAOT-LLVM have not taken this route.

2. Use a local Linux container from the CLI on macOS

Add Docker, OrbStack, or another container/VM runtime as a dependency for macOS users building C# modules. The CLI would start a Linux container with dotnet and the WASI SDK, run dotnet build inside the container, copy the resulting WebAssembly artifact back to the host, then clean up the container.

This should be reasonable to implement, but it introduces a third-party virtualization dependency that users must install manually. The Linux image would likely be over 1 GB, so the first run would be slow. The CLI would need to explain the dependency, image download, build environment, and cleanup behavior clearly.

3. Add a cloud build service

We can package the C# module project, upload it to a SpacetimeDB build service, do the build and send the compiled WebAssembly artifact back to the user.

This is probably the best user experience for users who are online and comfortable sending their source code to us. However, it requires us to build and operate a new service. We would need to handle sandboxing, dependency restore, privacy, logs, abuse prevention, cost controls, caching, and reproducibility.

4. Offer official Linux container image

Publish and document an official Linux container image for C# module builds. Users would run the build manually inside that environment.

This is less polished than CLI-managed containers (option #2), but it offers a specific simpler supported workaround and makes it easier for the user.

No files or tests are named, and the issue presents several unselected approaches. Start by reviewing the existing C# module build path, CLI behavior, and documentation for macOS and .NET 10. A maintainer decision is needed before implementation; done would mean one supported approach is implemented, documented, and tested on macOS.