Codegen silently ignores explicit enum discriminant values

Problem

When a Rust module defines an enum with explicit discriminant values:

#[derive(SpacetimeType)]
enum MyEnum {
    A = 1,
    B = 2,
    C = 3,
}

SATS encoding assigns variant tags by declaration order (0, 1, 2), completely ignoring the Rust discriminant values (1, 2, 3). Client-side codegen then generates enums with the SATS tag order, resulting in a mismatch between server and client enum values.

This means the server thinks A = 1 but the client thinks A = 0, silently corrupting data when enum values are used for anything beyond pattern matching.

Expected Behavior

The derive macro should emit a compile error when explicit discriminant values are used, since they cannot be preserved through the SATS encoding.

Start by locating the SpacetimeType derive macro and the SATS enum encoding path described in the issue. Trace how explicit Rust discriminants are handled, then add coverage showing that such enums produce a compile error rather than declaration-order tags; done means the server and client cannot silently disagree on these values.