A reserved-word column (e.g. value) silently mis-parses inside a SQL aggregate — wrong result, no error

## Summary
A column whose name is a Harper SQL reserved word (e.g. `value`) used UNQUOTED inside an aggregate function silently mis-parses and returns a wrong result with NO error:
- `SUM(value)` / `AVG(value)` → junk (`"[object Object]…"` string in a `GROUP BY` row, or `null` in a scalar aggregate).
- `COUNT(*)` is unaffected.
- Backticking (`` SUM(`value`) ``) fixes it and the aggregate becomes exact.

This is sharper than the general reserved-word quoting requirement: reserved words elsewhere error LOUDLY (400), but inside an aggregate function the column degrades QUIETLY to a wrong answer — a silent-wrong-result footgun.

## Impact
Low-medium, but it's silent (no error), so a customer with a `value`/`count`/etc. column gets wrong aggregates without any signal.

## Suggested fix
Reject an unquoted reserved-word column inside an aggregate with a clear error (as elsewhere), rather than silently producing a wrong aggregate; and document the SQL reserved-word list + the backtick-quoting rule.

## Repro
`integrationTests/qa-scratch/timeseries.test.ts` (the `SUM(value)` GROUP BY case). Harper `001bf7b9c` (v5.1.0, main).

---
_Found via the exploratory QA campaign (qa-explorer), scenario QA-091._