Rebase the columnar fields and clustered indexes work onto the post-off-tokio tree

[pathscale]

PR #58 rebased onto feat/off-tokio (#103) and made green. #58 itself has been
CONFLICTING and untouched since 2026-08-06, with master 268 commits ahead of it.

Its two commits replay recognisably as the first two here; everything I had to
change to land them on the current tree is in two separate commits after, so the
adaptation can be audited apart from the original work.

The conflict was not what the diff suggested

The expensive change was not tokio::yield_now becoming worktable::prelude::yield_now.
That had already happened cleanly in files this never had to touch. The real
structural change is that codegen/src/common/{model,parser} was extracted into
the worktable_dsl crate, so every one of #58's schema-language files had to
move crates rather than merge. Thirteen conflicts, two of which needed judgement
rather than merging:

ColumnSlotIdExhausted rollback arms in reinsert and reinsert_cdc called
primary_index.insert(pk, old_link). On this tree the primary index is no
longer swung before the secondary-index work, so that rollback would have
written a spurious entry. Dropped in both, matching the sibling AlreadyExists
arm. Three further ColumnSlotIdExhausted arms were needed in paths added after
#58 was written.

Two bugs found while rebasing

worktable_dsl::schema mirrors the macro's section dispatch for the editor and
checker path, and had no columnar_indexes arm. A valid declaration parsed for
code generation and was then rejected by gen_schema_const. Fixed, and both
"expected one of" messages now list the section.

cargo check --no-default-features passes on feat/off-tokio and failed once
#58 landed: src/columnar.rs imported std::{collections, fmt, hash, sync} and
the generated side-index type named std::collections::BTreeSet and
std::mem::{take, replace}. Getting std out of the macro's contract is the
same goal as getting tokio out, so the module goes through alloc/core and
the emitted paths through the prelude. That is its own commit because CI may not
run that check and it would have shipped silently.

What the columnar lock actually costs

Worth stating plainly, because the PR description understates it and because it
decides which benchmarks have to be re-run.

A table that declares no columnar fields pays nothing, structurally rather
than approximately: every emitter in codegen/src/generators/columnar.rs opens
with if columns.columnar_fields.is_empty() { return quote!{} }, so no field is
declared, no lock constructed, and no #columnar_dirty token interpolated into
any update generator. Generated code for a non-columnar table is byte-identical
to pre-#58 output. So existing benchmark numbers stand and only columnar
benchmarks need re-running.

On a table that does declare columnar fields, every insert, delete, update,
in-place update and reinsert takes the exclusive lock. "Serializes concurrent
side-index writers" understates it: side-index writers are the whole
row-mutation path. And ensure_columnar_current() takes the writer lock
unconditionally on entry, before it can observe that dirty is false
(codegen/src/generators/columnar.rs:441-442), so concurrent readers of a clean
replica serialize against each other too. If this path is benchmarked, the
number that matters is row-mutation throughput on a columnar table against the
same schema without columnar.

Verification

	feat/off-tokio	here
cargo test	936	944
cargo test --workspace	1094	1116

Zero failures. cargo clippy --workspace --all-targets clean.
cargo tree -e normal -i tokio prints nothing; tokio stays a dev-dependency and
no tokio:: path was resurrected.

The PDF was not a merge problem: feat/off-tokio has neither .gitattributes
nor output/, so both applied as clean adds. Verified by blob hash rather than
by the status line, 38ac26c71522f5712560b3523acc1673bfddc942, 27746 bytes,
byte-identical to #58's.

Supersedes #58. Base is feat/off-tokio, so #103 lands first.

[pathscale]

Folded into #105, which now carries these four commits as the first four of one linear branch. The two touch the same three section-dispatch loops, so splitting them meant resolving the same conflict twice.