[zmofei]

Adds a commands search eval CI job that runs the commands search query sets on the PR and its base, and writes the scores, plus the queries the change fixed and broke, to the job summary. It never fails; the eval_set_* tests are the gate. Split out of #103 per review.

• MAPBOX_SEARCH_EVAL_REPORT makes the eval_set_* tests write each query's result to a directory, even when they fail.
• scripts/commands-search-report.py turns the head and base reports into the summary. The Required column shows the scores below which the tests fail (recorded score less the slack).
• scripts/test-commands-search-report.sh checks the summary against hand-written reports, run in the shell job.

No PR comment: the summary needs no write token, so fork PRs get it too.

Testing: actionlint, shellcheck, the report test and the full suite pass locally, and I ran the eval with reports and rendered the summary. Not verified: the job on GitHub, including the base comparison.

Stacked on #103; retarget to main once it merges.

[mattpodwysocki]

Looks good from a CI safety angle: pull_request only, read-only contents, no persisted credentials, the base SHA goes through env, and it only writes to the job summary. I ran it locally end to end and the table matches the tests. A few small things:

1. Against a base that has the eval tests but not the report writer (this PR's base, and main right after #103 merges), the summary says "the base predates the eval (its run had no eval tests)". Something like "the base run wrote no reports" would be accurate in both cases.
2. parse_line keys rows by query, so a query repeated in a set collapses into one row and the summary's counts can differ from what cargo test saw. I tried a set with the same query twice (one right, one wrong) and got "below its floor" while the test passed. A list instead of a dict, or rejecting duplicates as invalid rows on the Rust side, would close that.
3. Minor: the shared target dir only rebuilds the base because git worktree add runs after the head build and gives the base files newer timestamps. That's fine as ordered, but a short comment would keep someone from moving that step earlier.

It'll also need a quick rebase onto #103's latest (6e3e44c).

[zmofei]

Thanks! Fixed all three in a1a0bc4 and rebased onto 1dad149, the latest on #103.

1. The summary now says "The base run wrote no reports".
2. A repeated query is now an invalid row on the Rust side, so cargo test fails on it and the summary only sees the first occurrence. I checked by duplicating a query in tuning.tsv: the test fails and the report carries the # invalid line.
3. Added the comment. I didn't reproduce the mtime behavior myself.

[mattpodwysocki]

Thanks @zmofei, all three addressed, and rejecting a duplicated query on the Rust side too is a nice touch. Approving.