[P6] 分離レベル正当性チェッカー（アノマリーテストスイート）を追加する

[thawk105]

親イシュー: #28 / 旧 #35 を分割したうちの 1 つ（分離レベル正当性チェッカー担当）。
依存: #91（テストインフラの配線）完了後に着手。#92（共通コンポーネントのユニットテスト）とは並行可。

現状（2026-05-15）

• CI はビルドの成否しか見ておらず、プロトコルが主張する分離レベル（「Snapshot Isolation」「直列化可能」など）を検証する仕組みが一切ない。cc/ include/ common/ のどこにも anomaly / write skew / G0/G1/G2 / isolation を扱うコードはない。
• そのため、誤った実装のプロトコルを追加してもバグが検出されず、ベンチは数値を出し続ける。
• 前提となる TxExecutorLike concept（旧 [P1] TxExecutorコントラクトをC++20 conceptで明示する #31, CLOSED）は include/tx_executor_concept.hh に実装済みで、各プロトコルの TxExecutor インタフェース（read / update / insert / delete_record / scan / commit / abort）はコンパイル時に強制されている。アノマリーテストはこの共通インタフェース越しに各プロトコルを叩ける。
• [P6] テストインフラを機能させる（enable_testing + CI ctest + 孤立テスト接続） #91 で enable_testing() + gtest 接続 + テスト用 CMake ヘルパ + CI ctest ステップが整備される。本イシューはその上にアノマリーテストスイートを載せる。
• 対象プロトコル: cc/ 配下にビルド接続されている cicada / d2pl / ermia / mocc / mvto / oze / si / silo / ss2pl / tictoc の 10 個（旧 cc/occ は [P7] cc/occ/ をビルドに接続するか撤去するか決める #84 で撤去され master から削除済み）。

やること

• Adya / Berenson の既知のアノマリースケジュール（G0 dirty write, G1 dirty read, G2 anti-dependency cycle, write skew, read skew 等）を、TxExecutorLike インタフェース越しに実行するテストハーネスを設計する
• 各プロトコルが主張する分離レベルを単一の宣言的ソースで持つ（例: プロトコルごとに「許容するアノマリー / 禁止するアノマリー」を表で定義）。README.md / docs/protocols.md / CLAUDE.md の手動同期を増やさないこと
• 各プロトコル × 各アノマリーについて、合否がプロトコルの定義と一致するかを検証する:
  • SI を主張するプロトコル: write skew を許容することを確認
  • 直列化可能を主張するプロトコル: write skew を棄却することを確認
  • 定義と実挙動が食い違ったらテスト失敗とする
• このテストスイートを [P6] テストインフラを機能させる（enable_testing + CI ctest + 孤立テスト接続） #91 で追加された CI の ctest ステップに載せる

完了条件

• ビルドに接続された全プロトコルに分離レベル検証テストが存在すること
• 各プロトコルの実挙動が、宣言された分離レベル定義と一致すること（一致しなければ CI で落ちる）
• テストが CI 内の ctest で実行されること

備考

• 本イシューは CC 理論に踏み込む最も重いコンテキスト。include/ 共通部品の単体テスト（[P6] include/ 共通コンポーネントのユニットテストを追加する #92）とは独立に進められる。
• アノマリースケジュールの厳密な定義は Adya のPhD thesis / Berenson et al. "A Critique of ANSI SQL Isolation Levels" を参照。
• 編集対象は C++ テストコードと CMake。docs/coding-conventions_ja.md の規約を編集前に確認すること。