GraphQL introspection is effectively disabled (__schema/__type → 400) — blocks standard GraphQL tooling

## Summary
GraphQL introspection is effectively unavailable: `__schema`, `__type`, and full Apollo/GraphiQL introspection queries all return **HTTP 400 "Resource '__schema' not found"**, and `__typename` in sub-selections resolves to `null`.

## Root
`server/graphqlQuerying.ts` routes every top-level selection through `resources.getMatch(name, 'graphql')`, so the GraphQL meta-fields (`__schema`/`__type`) are treated as resource names and miss → 400. (This is also why a prior probe saw an "empty fields" introspection result — it's a 400/unsupported path, not an empty schema.)

## Impact
Severity MEDIUM (DX / adoption). Tooling that depends on introspection — Apollo Client, GraphiQL / Apollo Sandbox schema panel, `graphql-codegen`, IDE plugins, type-safe client generation — cannot work against Harper. A real blocker for GraphQL-first teams. Not data corruption; a capability gap.

## Disposition (needs a product call)
Likely a known limitation of Harper's custom (non-spec-complete) GraphQL engine — same bucket as unsupported mutations. Two options:
1. **Document** clearly that Harper GraphQL has no introspection (and no aliases — see the companion aliases issue) so teams don't expect standard tooling to work, or
2. **Add a minimal introspection responder** so the standard GraphQL tooling chain works.

## Repro test
`integrationTests/qa-scratch/qa160-graphql-introspection.test.ts` (Part A).

— from Harper exploratory QA (KrAIs)

Start with server/graphqlQuerying.ts and Part A of integrationTests/qa-scratch/qa160-graphql-introspection.test.ts to confirm how __schema, __type, and __typename are handled. Resolve the documented product direction—documentation or an introspection responder—then define completion around the selected behavior and corresponding regression coverage.

Written by the indexing model from the issue text.