OpenAPI adapter: definition errors outside the @http wiring are never reported

Product

Hot Chocolate — HotChocolate.Adapters.OpenApi.Core

Version

16.6.0-p.5

Link to minimal reproduction

https://github.com/alisan3/hc-openapi-adapter-repro

Steps to reproduce

git clone https://github.com/alisan3/hc-openapi-adapter-repro
cd hc-openapi-adapter-repro
dotnet run --project silent-diagnostics

No server or gateway involved — it builds an ISchemaDefinition from SDL and runs
OpenApiDefinitionValidator.Validate over four endpoint definitions.

What is expected?

A definition that cannot possibly execute should be reported somewhere before a client hits it —
ideally as an OpenApiDefinitionValidationError naming the definition and the offending selection,
in the same style as the existing route-parameter message, which is genuinely good:

Route parameter 'id' references variable '$id' which does not exist in the operation.

What is actually happening?

Validation covers the @http wiring only. Anything wrong with the operation itself is accepted:

Definition	Result
route placeholder {id} with no matching variable	caught
root field that does not exist on Query	IsValid = True
selected field that does not exist on the type	IsValid = True
spread of a fragment that no definition anywhere defines	IsValid = True

This is worse than an ordinary gap in validation coverage, because ValidationErrors is the only
member of IOpenApiDiagnosticEvents. If an error class cannot produce a validation error, there is
no channel through which it can ever be reported — no log level, and no custom
OpenApiDiagnosticEventListener, makes it visible. And IOpenApiDefinitionValidationContext exposes
only Schema, so cross-definition problems such as the dangling fragment spread are structurally
outside what the current validation signature can express.

The definitions then register, and the failure surfaces at request time as HTTP 500 with an empty
body.

Relevant log output

A. route placeholder {id} with no matching variable  -- caught
    IsValid = False
    error   : Route parameter 'id' references variable '$id' which does not exist in the operation.

B. root field does not exist on Query                -- silent
    IsValid = True

C. selected field does not exist on Thing            -- silent
    IsValid = True

D. spreads a fragment no definition defines          -- silent
    IsValid = True

Additional context

Found while building a REST facade over a Fusion gateway. We wrote an
OpenApiDiagnosticEventListener specifically to find out why endpoints were failing, and it stayed
quiet throughout — which is what sent us looking at the validation surface.

Case D is how #10214 presents in practice: fragments swallowed by a multi-fragment definition file
leave dangling spreads behind, and nothing anywhere says so. Fixing either one alone would have
saved the investigation, but this is the more general of the two — any typo in a definition file
currently costs the same hunt.

Two things that would each help a lot on their own:

1. Validate the operation against the schema, and resolve fragment references across definitions, so
   these become ordinary validation errors.
2. Fail loudly at startup for definitions that cannot execute, rather than registering a route that
   returns an empty 500.