Support spec_compliant_errors in Plug options

[donleandro]

Summary

This adds spec_compliant_errors as a supported option in Absinthe.Plug, so users can opt into the modern GraphQL spec error format (extra error fields nested under extensions instead of at the top level).

The option is added to @init_options, @raw_options, the @typedoc, and the @type. It flows through the same path as analyze_complexity, max_complexity, and token_limit.

There's one extra piece needed beyond just forwarding the option: Absinthe.Pipeline.for_document/2 lists Phase.Document.Result without options, so the option never reaches the Result phase on its own. To fix this, default_pipeline/2 now replaces the bare phase with {Phase.Document.Result, spec_compliant_errors: true} when the option is set.

Usage

plug Absinthe.Plug,
  schema: MyAppWeb.Schema,
  spec_compliant_errors: true

Or at runtime:

Absinthe.Plug.put_options(conn, spec_compliant_errors: true)

Context

I ran into this while building Shiko, a veterinary platform. We wanted consistent error formatting across our GraphQL API, and the spec_compliant_errors option in absinthe core was exactly what we needed - but it had no effect when configured through the Plug.

Test plan

• Test that init/1 places the option in raw_options
• Test that errors with extra fields have them nested under extensions when spec_compliant_errors: true
• Test that without the option, extra fields remain at the top level (backwards compatible)
• All 89 existing + new tests pass

Closes #284