Resync src/bruteforce.c with bruteforce.cu (target: future CLI build)

[felixx-sp]

Confidence: high · Effort: medium (1-3 d)

Problem

src/bruteforce.c is a pure-CPU implementation of the engine that is not linked into the production binary (build.bat only compiles bruteforce.cu). It is only used by build_test.bat to satisfy linker symbols in the test harness, and the test does not actually exercise any of its engine functions. As-is, the file has diverged from bruteforce.cu and is missing several key changes:

• The atomic race fix from CUDA: atomic race on best_key / best_score #1 (now done in .cu) is not in .c
• The strict chi-squared scoring component (added later in .cu) is missing
• Dictionary phase is missing
• KPA pre-filter integration is missing

This is intentional architecture, not dead code: bruteforce.c is being kept as the future basis for a CLI / Linux build target (see follow-up issue on headless CLI mode). But while it stays out of sync it is also a trap — a contributor "fixing a bug" in bruteforce.c would be editing the wrong file silently.

Files: src/bruteforce.c (795 lines), CONTRIBUTING.md

Suggested fix

Two acceptable approaches:

1. Port forward: apply the missing changes (atomic-race fix, chi² scoring, dictionary phase, KPA pre-filter) to bruteforce.c so it stays a valid CPU-only reference implementation.
2. Single-source: move the host scoring helpers to a shared bruteforce_host.c included by both .c and .cu, so divergence is structurally impossible.

Either way, also add a clear comment at the top of bruteforce.c stating its purpose (CPU-only reference for the future CLI build) so the next contributor knows.

Why it matters

Enables the future CLI / Linux build (separate issue) and removes a silent trap for contributors. Pairs with the CMake migration and POSIX HAL issues.