fix: revalidate unique-index updates after locking

[pathscale]

Summary

• Add opt-in post-lock primary-key and predicate revalidation for generated unique-index updates.
• Reject a changed or stale unique-index entry rather than mutating another row under the wrong lock.
• Apply the strict path to both in-memory and persisted generators.
• Add a regression test and document the compile-time feature.

Production-performance policy

• The strict path is enabled with the strict-unique-index-revalidation Cargo feature.
• The feature is off by default, so existing latency-sensitive builds generate the original update path.
• The hot select_by_unique read path is unchanged.

Performance measurements

• Five alternating master/strict pairs produced paired changes of +0.25%, +0.84%, +0.88%, +3.94%, and -3.54%. The final reversed-order pair exposed substantial thermal/order noise; the median paired effect was +0.84%.
• Earlier consecutive strict runs were stable near 4.65 us and initially appeared 2-3% slower than a 4.51 us master run. Because 2% is material for HFT, strict behavior is not enabled by default.
• Three alternating master/default-feature-off pairs detected no regression. The feature-off generator emits the original code path.

Verification

• cargo test
• cargo test --features strict-unique-index-revalidation --test mod worktable::index::update_query::unique_update_rejects_stale_index_link
• cargo clippy --all-targets
• cargo clippy --all-targets --features strict-unique-index-revalidation
• cargo fmt --all -- --check

[pathscale]

Superseded by #187, which consolidated and merged the backend-selection and publication hardening work after the combined review and validation rounds.