fix(eval): always reconfigure cmake, surface build errors on failure

[skyrocket2026]

Summary

build/ is gitignored, so it survives every git checkout on the eval box across PR/main evaluations. The build step only ran cmake -S . -B build when CMakeCache.txt was missing — meaning once any PR's branch added new source files (and matching CMakeLists.txt entries), the generated Makefiles kept referencing those files even after switching checkout to main or a different PR that never had them, failing with No such file or directory for files the checked-out tree doesn't reference at all.

Root-caused #693 (failed evaluating main itself) and #694 (failed evaluating its own branch) today — both hit stale Makefiles left over from a different PR's earlier build/configure on the shared box. Not a GPU/OOM issue at all, unlike #684/#690 (fixed in #692) — this one is fully deterministic once the build directory gets poisoned by a checkout that added-then-removed source files.

Fix

• Always reconfigure with cmake -S . -B build — cmake's own configure step is cheap and idempotent on an existing cache, so there's no reason to skip it.
• On a build failure, dump the last 80 lines of /tmp/dflash_build.log to stderr, so a REJECT from a real compile error shows the actual compiler diagnostic instead of a bare Error 2 with no context (this is what let me actually root-cause perf(dflash): widen the verify window past the compact graph's four-row limit #693/perf(dflash): row-batched exact verification kernels for Qwen3.6 speculative decode #694 by SSHing in manually — now it'll be visible directly in the PR comment).

Test plan

• python3 -m py_compile eval/pr_dflash_bot.py
• bash -n on the generated remote script
• Observe the next eval round on a PR that previously hit this (perf(dflash): widen the verify window past the compact graph's four-row limit #693/perf(dflash): row-batched exact verification kernels for Qwen3.6 speculative decode #694 rebased, or any new dflash PR) build and score cleanly