verify the query text against the persisted query id on cache hits - #4512

Spock, ApolloPersistedQuerySupportTest on master:

will have error if the query text does not match a query hash that is already cached FAILED
    er.data == null
    |  |    |
    |  |    false
    |  [secret:secret]

PersistedQuerySupport.getDocumentAsync only calls persistedQueryIdIsInvalid from the cache-miss callback. Once a hash is cached, any request carrying it runs the cached document whatever query text it sends: { public } sent with sha256 of { secret } executes { secret } with no error, while ExecutionInput.getQuery() (what instrumentation, logging and the execution id provider see) still says { public }. Apollo's server rejects this case with "provided sha does not match query", and #2395 asked for the same error whenever both a hash and a query are present.

The check now runs before the cache lookup when real query text is sent (not blank, not PERSISTED_QUERY_MARKER). The base persistedQueryIdIsInvalid still returns false, so only ApolloPersistedQuerySupport behaves differently. The existing "hash in preference to query text" test asserted the old behaviour, so it now sends matching text, and new cases cover the mismatch at the unit level and end to end through GraphQL.