Fix issues with tuple primary key in-memory and for persistence

[pathscale]

As I found tuple primary key has some unimplemented parts (for example queries by pk if it is tuple). This things should be fixed, as this logic is very usable

---

Migrated from pathscale/wt-dead#72. Originally opened by @Handy-caT on 2025-04-15T12:22:06Z.

[pathscale]

Confirmed as a real persistence bug on clean origin/master. A temporary probe with two u64 primary-key columns compiled, inserted (1, 2), drained, and reopened successfully, but select((1, 2)) returned None after reload. In-memory tuple lookup passes. Acceptance must cover persisted insert, reload, point/range lookup, update, delete, and a format/migration test for tuple keys.

[pathscale]

The PR #46 tuple-key fix passes its full acceptance path: persisted insert, close/reload, point lookup, range lookup, update, delete, second close/reload. The exact regression passed 25/25 fresh-process repetitions on the PR merge ref. This issue appears resolved; recommend closing when PR #46 lands.

[pathscale]

Resolved by merged PR #46 and released in worktable 1.0.0-beta.3. The persisted composite-primary-key regression covers insert, clean close/reload, point lookup, range lookup, update, delete, and a second close/reload; it passed 25/25 fresh-process repetitions before merge, and all final CI feature matrices passed.