fix(QueryFormatter): forward GROUP BY to SelectFirst and SelectCount

[Yaraslaut]

Fixes #559.

Problem

SqlQueryFormatter::SelectFirst and SelectCount took no groupBy parameter, so a populated ComposedQuery::groupBy could never reach them — .GroupBy(...).First() and .GroupBy(...).Count() silently returned ungrouped results. SelectAll and SelectRange already took it, which is what marks the omission as accidental.

q.FromTable("T").Select().Field("a").GroupBy("a").First().ToSql();
// before: SELECT "a" FROM "T" LIMIT 1        <- GROUP BY dropped
// after:  SELECT "a" FROM "T" GROUP BY "a" LIMIT 1

Change

• Added std::string_view groupBy to both virtuals, positioned after orderBy to match SelectRange.
• Implemented in SQLiteQueryFormatter (SelectCount + SelectFirst, inherited by PostgreSQL) and SqlServerQueryFormatter (SelectFirst). The clause is emitted between WHERE and ORDER BY, exactly as SelectAll/SelectRange already do.
• Forwarded from ComposedQuery::ToSql in the First and Count branches.
• The DataMapper query builder calls the formatter directly rather than through ToSql, so it had the same bug at 7 further sites — CountImpl, ExistImpl, the three FirstImpl overloads and both FirstImpl(n) overloads. All now pass the builder's groupBy.
• Documented the grouped-count semantics on both Count() surfaces: SELECT COUNT(*) … GROUP BY x yields one row per group, and the DataMapper's Count() returns the first group's count since it reads a single value.

HAVING is still unsupported — noted in the issue as a separate gap, deliberately left out of scope here.

Tests

Three cases in QueryBuilderTests.cpp covering Count()+GroupBy, First()+GroupBy and First(3)+GroupBy+OrderBy across all three dialects. All three fail on master (GROUP BY absent from the generated SQL) and pass with this change.

Risk

Source/ABI break for any out-of-tree SqlQueryFormatter implementation, as the issue anticipated; every in-tree implementor is updated. Behaviour is unchanged wherever groupBy is empty — the generated SQL is byte-identical, which is why the rest of the suite is unaffected.

Performance: no measurable impact — one extra string_view argument and one stream insertion of an empty view on the unchanged paths.

Verification

• SQLite / clang-debug (ASan+UBSan+clang-tidy) on this exact commit in a clean tree: 1405 cases, 13641 assertions, all pass (1 pre-existing skip). Build is warning-free; clang-format applied.
• mssql2022 and postgres (Docker) were run green on this change earlier in the session — 13618 and 13571 assertions respectively, 0 failures — but in a working tree that also carried unrelated in-flight work, and a re-run against this exact commit was not possible because the containers were being used concurrently by another session (the suite drops all tables at fixture setup, so parallel runs corrupt each other). Worth confirming in CI.
• Not run locally: gcc-release. No GCC toolchain on this machine, so the compiler CI's database legs actually use is unverified here.

[codecov]

Codecov Report

❌ Patch coverage is 93.75000% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/Lightweight/QueryFormatter/SQLiteFormatter.hpp	75.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!