Fix record corruption when fields are reordered in table config

[larsewi]

Summary

• Tuple identity in Table records (both primary key and subsidiary halves) was tied to the declaration order of fields in tables.toml. Swapping two fields in the config silently changed every row's hash key, breaking delta merging against pre-swap state and historical blocks.
• Make the tuple layout canonical: sort fields lexicographically by name within the primary-key and subsidiary groups. The same config produces the same tuple identity regardless of how the user wrote the field list.
• compute_canonical_columns returns each tuple slot as a (column_index, &FieldConfig) pair, so the index and parser can't drift; parse_columns consumes the bundled slice directly.
• SQL emission still follows wire order. Now that the wire is canonical, generated INSERT column lists and composite-PK WHERE clauses appear in lexicographic order. A follow-up PR will route SQL through the hub's declared field order so users keep their preferred column ordering in generated SQL.

Notes for reviewers

• accept_composite_pk.rs had its expected SQL updated to reflect the canonical column order (course_id before student_id). The follow-up that reroutes SQL emission will flip these assertions back.
• Existing on-disk STATE / blocks written before this change carry tuples in declaration order. The first run after upgrade will hit the existing layout-mismatch path in Delta::compute / merge_block_deltas and fall back to a full state payload, so no migration code is needed.