B-tree indexes on non-unit (payload-carrying) enums

Summary
Allow #[index(btree)] (and multi-column indexes) on enums that carry data, not just unit/C-style enums.

Discord conversation

Motivation / Use case
A very common pattern is an “intent” or “state” enum that sometimes references another entity:

#[derive(SpacetimeType)]
pub enum MoveIntent {
    Path(WorldPos),
    Position(WorldPos),
    Direction(u8),
    ChaseAttack(ActorId),   // ← want to find all rows where this == some ActorId
}

#[table(accessor = move_state_tbl)]
pub struct MoveState {
    pub intent: MoveIntent,
    #[primary_key]
    pub actor_id: ActorId,
    pub zone: ZoneName,
}

When an actor leaves a zone I need to efficiently find every other actor that is currently chasing them (MoveIntent::ChaseAttack(their_id)) and clear those move states.

Current work-arounds

1. Full table scan (.iter() + filter) — simple but O(n).
2. Manually pack the enum into two columns (kind: u8 + payload: u32) and put a multi-column B-tree on them.
3. Maintain a separate “chasers” table with its own index on target_id.

All three work, but they either cost performance or force awkward denormalisation.

Suggested behaviour
Ideally the index would support both:

• Equality on a whole variant: intent.filter(MoveIntent::ChaseAttack(id))
• Or at least equality / range on the payload of a specific variant (the most useful part for this pattern).

Even a restricted form that only lets you index “the payload of variant X” would already solve the majority of real-world cases.

No source files, tests, or entry points are named. Start by locating the #[index(btree)] implementation and multi-column index handling, then trace how enum indexes currently restrict unit/C-style enums. Done should include a defined supported behavior for payload-carrying variants, including the MoveIntent::ChaseAttack(id) use case, with coverage for whole-variant or payload equality and range queries as supported.