Decode u64s

[frankmcsherry]

The result of work with Claude code. This summary was written by Claude:

  Summary

  Adds a new decode path (decode_u64s + from_u64s) that preserves u64 alignment
  information through the entire pipeline, enabling LLVM to eliminate unused tuple
   fields as dead code.

  The key insight: decode returns &[u8], which discards the alignment guarantee
  that the &[u64] store provides. from_bytes must then re-prove alignment via
  bytemuck::try_cast_slice for every field — a panicking operation that LLVM
  cannot eliminate, forcing O(k) work to access any field of a k-tuple. The new
  path returns (&[u64], u8) pairs (word slice + trailing byte count), making all
  casts infallible and all construction non-panicking. LLVM sees unused fields as
  pure dead code and removes them.

  Assembly: accessing field 0 of a k-tuple of u64s

  ┌─────┬────────────────────────┬──────────────────────┐
  │  k  │  from_bytes (before)   │  from_u64s (after)   │
  ├─────┼────────────────────────┼──────────────────────┤
  │ 1   │ 77 insns, 8 branches   │ 68 insns, 7 branches │
  ├─────┼────────────────────────┼──────────────────────┤
  │ 3   │ 133 insns, 14 branches │ 68 insns, 7 branches │
  ├─────┼────────────────────────┼──────────────────────┤
  │ 8   │ 273 insns, 29 branches │ 68 insns, 7 branches │
  └─────┴────────────────────────┴──────────────────────┘

  Also removes the EncodeDecode trait and Sequence encoding (superseded by
  Indexed), renames the module to indexed, and adds FromBytes::validate for
  upfront data validation at trust boundaries.

[frankmcsherry]

There is still an increasing number of instructions for fields beyond 0, but saving that for a different PR. It seems likely related to taking larger steps through the iterator, removing the sequential dependencies, whereas this is mostly about tweaking the codegen to avoid panics.