Describe the bug

The docs state that createdAt, updatedAt, and id are built-in columns that "you can still filter and sort on". Sorting on these works. Filtering on them does not. Any filter referencing a built-in column silently matches nothing and returns an empty result set.

To Reproduce

Via the v1 API:

GET /api/v1/tables/{tableId}/rows?workspaceId={wsId}&filter={"createdAt":{"$gte":"2026-07-24T03:00:00.000Z","$lte":"2026-07-25T02:59:59.999Z"}}

With a string value, returns 400 Bad Request:

{
  "error": "Range operator on column \"createdAt\" (number) requires a number, got string"
}

With a numeric value (Unix timestamp)

{ "rows": [], "rowCount": 0, "totalCount": 0 }

Passes validation, but returns empty results. No error, no warning, just zero rows regardless of how many rows match the range.

Expected behavior

Filters on createdAt / updatedAt / id compare against the top-level row columns (user_table_rows.createdAt, etc.) and return matching rows, mirroring the behavior the sort builder already provides.

Additional context

I think I can open a PR to solve this, if this intend to work the way I've described it.