GraphQL silently ignores per-level filter/limit args on nested relationship fields (over-broad results)

## Summary
Filter/limit arguments on a NESTED relationship field in a GraphQL query are silently dropped — the query returns over-broad data with HTTP 200 and no error/diagnostic, so a client trusts wrong results.

Example: `customer { orders(status:"open", limit:2) { lineItems(qty:3) { … } } }` returns ALL orders (incl. closed) and ALL line-items — the nested `status`/`limit`/`qty` args are ignored (not mis-scoped, not applied globally, just dropped).

## Root cause
`server/graphqlQuerying.ts` `buildSelectQuery` (~L286-295) builds nested selections as `{name, select}` and never reads `fieldNode.arguments`; arguments are only processed at the top level (`processFieldNode`→`buildConditionsQuery`).

## Related (sibling, top-level surface)
At the TOP level, non-equality args fare differently: a top-level `Type(limit:N)`/`sort`/operator arg is mis-coerced to an equality condition on a non-existent attribute → HTTP 500 ("limit is not a defined attribute"), and one bad arg poisons the whole query. So GraphQL has no real pagination/sort/operator arg surface at all: nested args are silently ignored, top-level non-equality args loudly error. (The 500 there should be a 4xx — ties the GraphQL-error-status issue #1299.)

## Suggested fix
Either honor nested-relationship-field args (filter/limit/sort) in `buildSelectQuery`, or reject unsupported nested args with a clear error rather than silently dropping them; and add top-level `limit`/`offset`/`sort` support (or a clear 400). Document the supported GraphQL arg surface.

## Repro
`integrationTests/qa-scratch/graphql-chained.test.ts` (nested, silent-ignore); `integrationTests/qa-scratch/graphql-toplevel-args.test.ts` (top-level error).

---
_Found via the exploratory QA campaign (qa-explorer), scenarios QA-093/098. Harper `001bf7b9c` (v5.1.0, main)._