Add support for the HTTP QUERY method as a safe/idempotent alternative to GET for complex read operations

Is your feature request related to a problem? Please describe.
Yes. Microsoft Graph read operations rely on GET with all query options ($filter, $select, $expand, $search, $orderby, etc.) encoded in the URI. For complex queries this runs into URI length limits — long $filter expressions, deep $expand chains, or large structured search criteria can produce requests that exceed what Graph, proxies, and other intermediaries accept, resulting in request failures.
The usual workaround is to switch to POST, but POST is neither safe nor idempotent, so responses can't be safely cached and failed requests can't be automatically retried.
Describe the solution you'd like
Add support for the HTTP QUERY method as an alternative to GET on read endpoints, carrying the query in the request body instead of the URI.
QUERY is defined in the IETF Internet-Draft draft-ietf-httpbis-safe-method-w-body ("The HTTP QUERY Method"). Its relevant properties, per the draft:

It is safe and idempotent with respect to the request URI — it does not alter resource state.
The request content and its media type define the query; any media type with appropriate query semantics may be used.
It is functionally similar to POST but, being safe/idempotent, requests can be automatically repeated or restarted without concern for partial state changes.

Note on status: as of draft -14 (Nov 2025) this is a Standards-Track Internet-Draft, not yet a published RFC. Please verify current status before relying on it.
Proposed behavior for Graph:

Accept QUERY on read endpoints as an alternative to GET, with OData query options supplied in the request body.
Keep GET fully unchanged — QUERY is purely additive, same response shapes and semantics.
Support conditional requests (ETag / If-None-Match) so responses remain cacheable.

Design details to discuss (not spec-confirmed): ideally the query body format would be discoverable (the draft defines an Accept-Query response header for advertising supported query formats), with standard status codes for malformed/unsupported/unprocessable queries. I'm noting these from memory of the draft — the maintainers and the spec text should be the authority on the exact mechanics.

Describe alternatives you've considered

GET with URI-encoded options (current) — hits URI length limits on complex queries.
POST as a query workaround — works but sacrifices safety, idempotency, and cacheability, and overloads a method meant for writes.
Client-side query splitting / pagination — added complexity and often not equivalent for filter/search semantics.

QUERY addresses the root cause in a standards-based, cache-friendly way.
Additional context

The HTTP QUERY Method (IETF datatracker): https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/
Working group source/issues: https://github.com/httpwg/http-extensions/labels/query-method

Start by reviewing the repository's TypeScript/React request flow and the linked IETF HTTP QUERY Method draft, since no implementation files or tests are identified. Confirm the draft's current status and the Graph API design before defining the request format, then establish tests for QUERY read requests, unchanged GET behavior, conditional requests, and malformed or unsupported queries.