GraphQL aliases are silently ignored — response key is always the field name

## Summary
GraphQL field **aliases** are silently dropped: the response key is always the underlying field name, never the alias. Any query relying on aliases gets wrong/missing keys, with no error.

## Repro
harper main f447404b6 (v5.1.13).
```graphql
{ Author { aliasedId: id aliasedName: name } }
```
Returns `{ id, name }` instead of `{ aliasedId, aliasedName }`. An N-alias query (`a0: name, a1: name, …, aN: name`) collapses to a single `name` key.

## Root
`buildSelectQuery` (`server/graphqlQuerying.ts:290`) uses `fieldNode.name.value` rather than `fieldNode.alias?.value`, so all alias variants of a field collapse onto one response key under the underlying field name. Per the GraphQL spec (Field Selection Merging / Aliases), an alias MUST rename the response key.

## Impact
Severity MEDIUM — silent correctness defect / spec violation. Any client using aliases to rename or distinguish response fields gets silently wrong data. (Incidental side effect: this also blocks alias-based response amplification, but that's not a substitute for the cost-limiting in #1291.)

## Repro test
`integrationTests/qa-scratch/qa160-graphql-introspection.test.ts` (B1/B2/B5).

— from Harper exploratory QA (KrAIs)

Start in server/graphqlQuerying.ts at buildSelectQuery around line 290, then read the B1/B2/B5 cases in integrationTests/qa-scratch/qa160-graphql-introspection.test.ts. Verify that aliased fields use their aliases as response keys, while unaliased fields retain their names and distinct aliases do not collapse. Run the referenced integration test to confirm the expected responses.

Written by the indexing model from the issue text.