C# submodules

[lisandroct]

Description of Changes

Implements C# submodules (namespacing), following the proposal and reusing the existing V10 submodule representation.

• Automatically discovers and registers referenced C# module assemblies.
• Adds assembly-level [Namespace(typeof(AuthLib.Marker), Accessor = "MyAuth", Name = "auth_data" )] declarations. Accessor controls C# access; optional Name specifies the canonical database namespace. When omitted, the host derives it using the root module’s case-conversion policy. Dependencies without a namespace declaration register in public.
• Allows the same module assembly to be published independently or used as a dependency, without a separate library build role.
• Shares .NET 10 contexts across assemblies. Root code accesses ctx.Db.MyAuth.User; library helpers retain ctx.Db.User and use the caller’s context and transaction.
• Supports namespace-aware tables, indexes, views, query builders, and scheduled reducers/procedures.
• Generates nested C# client table, reducer, procedure, and subscription accessors using one connection and cache.
• Caches resolved lookup names, SQL names, and index handles to avoid repeated resolution and unnecessary allocations.
• Adds diagnostics, documentation, CI coverage, and focused integration tests.

API and ABI breaking changes

No changes to host, it uses the existing RawSubmoduleV10 for accessor namespaces and the existing ExplicitNames namespace mappings for canonical names.

On .NET 10, contexts move from generated module types into Runtime, changing their assembly identity. Existing standalone .NET 8 modules retain generated contexts.

Rollback safety impact

n/a

Expected complexity level and risk

4/5. This PR touches a lot of systems: source generation, runtime registration, NativeAOT publication, schema composition, function dispatch, client generation, subscriptions, ... possibly more.

The main risks are incorrect assembly ownership or dispatch ordering, cross-namespace lookup mistakes, NativeAOT export/trimming behavior, and regressions in existing flat modules.

Testing

• .NET 8 and .NET 10 generator/Verify suites; regenerated snapshots.
• Rust codegen tests, including C# bindings generated from a TypeScript submodule.
• NativeAOT publication, root export selection, and cross-library helper/HTTP integration.
• Namespace client integration: subscriptions, callbacks, indexes, views, events, private tables, one-off queries, and unsubscribe cleanup.
• Namespaced scheduled reducers/procedures and cross-namespace transaction commit/rollback.
• Root-defined RLS targeting namespaced tables and environment-security integration.
• Distinct accessor/canonical names (MyAuth → auth_data) and default namespace case conversion (MyAuth → my_auth).
• Full C# SDK unit-test suite.

[JasonAtClockwork]

Everything works as intended but I did find some differences between how the TypeScript submodules work compared against the C#. I'm not certain if any of these are real problems so we may want a discussion around them:

1. HTTP routes from submodules are ignored in TypeScript but are bound to the root in C# (which can cause collisions)
2. TypeScript supports nested submodules, and generating a C# client against a TypeScript module with nested submodules causes spacetime generate to panic
3. TypeScript submodules are declared, not discovered. C# discovers every referenced module and merges anything not mounted into the root (master currently just ignored them), which can cause collisions with the root's reducers, Init, or types and allows access to root env variables.

Super low priority: Codegen.Tests fails on Windows however is fine on Linux

[lisandroct]

1. HTTP routes from submodules are ignored in TypeScript but are bound to the root in C# (which can cause collisions)

The proposal doesn't say anything about HTTP handlers. I decided to not ignore them, but it might be better to do so.

2. TypeScript supports nested submodules, and generating a C# client against a TypeScript module with nested submodules causes `spacetime generate` to panic

The proposal only describes submodules being defined in root and I was under the impression that the plan was to not support nested submodules, so I just didn't add support to them. But now I'm not sure. Maybe we do want them?

3. TypeScript submodules are declared, not discovered. C# discovers every referenced module and merges anything not mounted into the root (master currently just ignored them), which can cause collisions with the root's reducers, Init, or types and allows access to root env variables.

The proposal states: "A library added as a dependency and otherwise ignored still has its tables register in public, exactly as today; what changes is that the consumer can redirect them to a named namespace via a mount declaration". So I understand the behavior on this branch is the desired one. All dependencies are registered in public unless root defines a namespace for them.

[JasonAtClockwork]

LGTM

[jdetter]

I think I'm only required for the CI change and that looks fine to me. I didn't review any of the other code.