Implement event tables

[cloutiertyler]

Description of Changes

Adds event tables support to SpacetimeDB (Rust server bindings only, V10 ABI).

Event tables are write-only tables whose rows persist to the commitlog but are NOT merged into committed state. Their rows are ephemeral in memory — only visible to V2 subscribers in the transaction that inserted them.

Schema & ABI:

• Add is_event: bool to RawTableDefV10, TableDef, and TableSchema
• New st_event_table system table (TableId 17) tracks which tables are event tables, avoiding migration of StTableRow
• is_event is reconstructed from st_event_table in schema_for_table_raw()

Rust bindings macro:

• Add event keyword: #[spacetimedb::table(name = my_events, public, event)]
• Emits const IS_EVENT: bool = true; on TableInternal
• Wired through register_table() to V10 builder's .with_event()

Core behavior:

• merge_apply_inserts(): event table rows are recorded in TxData (for commitlog + subscriptions) but skip merging into committed state
• replay_insert(): event table rows return early — no committed state rebuilt on restart

Compile-time semi-join validation:

• CanBeLookupTable marker trait in query-builder — event tables don't implement it
• Semi-join methods require R: CanBeLookupTable, giving a compile error if an event table is used as the lookup side

Cherry-picks joshua/shub/raw-module-def-v10 (#4153) as a prerequisite. V9 is completely untouched.

Deferred: V2 subscription evaluation, runtime SQL semi-join validation, view validation.

API and ABI breaking changes

New field is_event: bool added to RawTableDefV10 (appended at end for ABI compat). Defaults to false, so existing modules are unaffected.

CanBeLookupTable trait bound replaces HasIxCols on semi-join methods in the query builder. All non-event tables implement CanBeLookupTable, so existing code compiles unchanged.

Expected complexity level and risk

3 — The changes touch the schema pipeline end-to-end (raw def → validated def → runtime schema → system table → committed state merge/replay), but each individual change is straightforward. The main risk area is the merge skip logic in committed_state.rs, which is on the hot path and must correctly distinguish event tables from persistent ones. The system table approach avoids any migration risk for existing databases.

Testing

• cargo check passes (verified locally)
• Verify event table inserts are recorded in TxData for commitlog persistence
• Verify committed state remains empty for event tables after merge
• Verify replay skips event table rows (state stays empty after restart)
• Verify compile error when using event table as right side of query builder semi-join
• Verify non-event tables are completely unaffected

[Centril]

A few things:

• It would be good to review and land the datastore changes first.
• When doing so, let's add unit tests (in the datastore crate) asserting that:
  a) an insert/delete pair does nothing to committed state (check this by querying txn +1) and neither to TxData.
  b) an update does nothing to committed state and neither to TxData.
  c) an insertion to an event table results in no changes to committed state and 1 change to TxData.
  d) replaying should also be tested as a unit test by saving the commitlog and then replaying and checking committed state after.
• I didn't see any code handling migrations from/to event tables. Ostensibly, such transitions should not be allowed. If this is already the case, a test confirming so would be good.