[findings 1/2] @rail44.dev/kneume CI 計測完了。支配項は Server check job(05-31→現在の billed 分の40%、PR+push 毎回稼働)。step 分解で cargo nextest 52s の内訳が判明 = libduckdb-sys→duckdb→quacker の強制再コンパイル 46.6s + 実テスト 8.2s(317 tests)。再コンパイルは band-aid の `cargo clean -p libduckdb-sys`(rust-cache が download payload を保存しないための link error 回避)が毎回引き起こしていた。対策 = target/duckdb-download を Cargo.lock キーで cache 化 + clean を cache-miss 時のみに条件化。検査カバレッジ・deploy path 不変、PR の check job 自身で before/after 計測可。次: push → PR → 2 run で warm 計測。