Cap rule combinations before their count can overflow

[Floating-Y]

Why

Both rule evaluators multiplied all candidate counts before checking the 64-combination cap. With two candidates in each of 64 conditions, the unchecked usize product panics in Debug. The default Release profile can wrap that count and bypass the cap; resource exhaustion in the unpatched Release evaluator remains a source-level inference, not a measured result.

Closes #1214.

What changes

• Use one private, incremental checked_mul guard in the ordinary and joined paths, stopping when the count overflows or exceeds 64 before building the Cartesian product.
• Preserve exactly 64 combinations, existing capped reporting, and evaluation of other eligible OR groups. Candidate nonempty checks stay ahead of the cap check.
• Add a table-driven evaluator regression covering both paths with 64, 128, overflow-sized, and overflow-plus-valid-OR inputs. Only the valid OR cases recheck their precise premises.

How it was checked

Checked the final source tree now committed as 6dd0d64d95be44b053fc2e2e2d632a668d16c0fc, based on dev at 259931ac702623351c2ed4e6487474790e57a6b0, on Windows x86_64 with Rust/Cargo 1.98.1 and Node 22.20.0.

• Before the production fix, the new Debug regression failed with attempt to multiply with overflow.
• cargo fmt --all --check and git diff --check: passed.
• cargo clippy --locked --workspace --all-targets -- -D warnings: passed.
• After migrating a disposable pgvector/pgvector:pg16 database, cargo test --locked --workspace --no-fail-fast with RUST_TEST_THREADS=4, UTOPIA_TEST_REQUIRE_DB=1, UTOPIA_TEST_REQUIRE_PDFTOTEXT=1, and the test database configured: 1,515 passed, 0 failed, 6 existing ignored tests. The ignored tests require live services or opt-in process/delivery experiments. The disposable database was removed afterward.
• cargo test --locked --release -p utopia-reason --quiet: 108 passed, 0 failed, 0 ignored.
• In web/, pnpm install --frozen-lockfile and pnpm build: passed, including the style guard and TypeScript check.

The first workspace run at the machine's default 22 test threads had two server test failures: failed_document_chunks_do_not_become_a_successful_empty_document returned Windows directory cleanup error 145, and the_embedding_gate_is_never_held_beyond_its_ceiling exceeded its elapsed-time bound. Both passed unchanged in isolated reruns, and the complete four-thread run above passed. Neither test, assertion, nor threshold was changed. Linux CI is still required.

Before review

• Every commit is signed off (git commit -s).
• Workspace format, Clippy with warnings denied, and workspace tests pass with the environment described above.

[WaylandYang]

Thank you for the report and the fix together.

The guard is right: the count is checked as it grows, so it stops at the cap before the product can overflow, and exactly 64 still passes. I ran the new test: it passes on the branch, and with the unchecked product put back it panics with attempt to multiply with overflow, as described.

Merging. Thanks again.