feat: add table accessor without lifetime

[onx2]

Description of Changes

Adds a lifetime-aware TableAccessor trait to the Rust SDK and updates Rust codegen to emit a generated accessor marker type for each table.

Generated bindings now include a marker type like:

pub struct PlayerPositionTableAccessor;

impl __sdk::TableAccessor<super::RemoteTables> for PlayerPositionTableAccessor {
    type Row = PlayerPositionRow;
    type Handle<'db> = PlayerPositionTableHandle<'db>;

    fn get<'db>(db: &'db super::RemoteTables) -> Self::Handle<'db> {
        db.player_position()
    }
}

The existing generated table access methods remain unchanged:

fn player_position(&self) -> PlayerPositionTableHandle<'_>;

Motivation

Generated table handles are lifetime-scoped to RemoteTables, which makes it difficult for downstream crates to expose ergonomic generic APIs over generated table accessors. In particular, a method like RemoteTables::player_position returns a handle whose type depends on the borrow lifetime of RemoteTables, which is hard to represent in higher-order APIs.

The existing lifetime is not mechanically required by the current handle storage model: generated table handles own an SDK TableHandle<Row>, which holds shared connection/cache state rather than borrowing from RemoteTables. However, the lifetime does express the conceptual scope of a handle relative to the database view that produced it.

This PR preserves that scoped API contract instead of removing the lifetime, and adds a generated marker type so generic downstream APIs can name table accessors without erasing or weakening the lifetime relationship.

This enables APIs such as:

.add_table::<PlayerPositionTableAccessor>()

instead of requiring closure-based registration everywhere.

API and ABI breaking changes

None.

This is additive and should not break existing generated bindings usage. Existing code such as the below continues to work unchanged:

ctx.db.player_position().on_insert(...)

The new TableAccessor trait is exported from both the SDK root and __codegen, and generated marker types are added alongside existing generated table handles and access traits.

Expected complexity level and risk

Complexity: 2/5

The change is small and additive, but it touches Rust SDK codegen and generated binding shape. The main risk is introducing generated code that depends on the new SDK trait, so generated bindings and the SDK version must match.

This does not alter table handle ownership, callback behavior, or existing access methods.

Testing

• Ran cargo check -p spacetimedb-sdk.
• Regenerated Rust bindings for my game.
• Verified generated bindings include *TableAccessor marker types.
• Used generated accessors from downstream local bevy_stdb.
• Ran cargo check -p bevy_stdb against the local SDK.

[onx2]

I'm not sure why there are lifetimes on the currently generated code, it doesn't seem like they are necessary 🤔 If someone could give me some more info on that I'd appreciate it!

Nevertheless, I didn't want to introduce breaking changes so this is simply additive. If lifetimes aren't needed in the code, then I'd like to see them eventually removed in the next breaking release.

[gefjon]

Table handles are scoped to the lifetime of the context because (other than the root DbConnection) a context object logcally refers to a single particular database state, and reads through that context object should always return information as of that state. As you've noticed, internally the client cache is a big shared mutable data structure which is not persistent (in the functional data structures sense). So we restrict the lifetime of the table accessors to the scope where that context's state is reflected in the cache.