pass: field-argument check false-positives on valid GraphQL subscription IR

[OmarAlJarrah]

Summary

checkArgsOutsideGraphQL computes GraphQL reachability with walkOperationRefs, which does not traverse ResponseStream.Events. Per ir/bindings.go, GraphQL subscriptions bind "plus streaming fields on the core", and per ir-design.md §5.1 field arguments are legal on any GraphQL-reachable model. An event model referenced only via ResponseStream.Events is invisible to the reachability walk, so its legal Property.Args are flagged with the severity-error diagnostic pass/args-outside-graphql.

The same false positive fires for models reachable only through Property.Args parameter types (nested field arguments) or template instantiation args — all unwalked sites.

Reproduction

A subscription operation with a GraphQL binding and ResponseStream.Events → t/ev, where t/ev has a property with Args, yields pass/args-outside-graphql on valid IR.

Root cause

pass/validate.go:358-402 (checkArgsOutsideGraphQL/graphqlReachableTypes) built on the incomplete walker (see #50 for the walker gaps).

Expected

Reachability must traverse every TypeRef site an operation can reference — streams, argument types, instantiation args. Concrete impact: the first GraphQL compiler that emits a subscription gets its valid document rejected (structural errors are fatal per architecture.md), so this blocks a documented near-term milestone.

[OmarAlJarrah]

The headline case here does not reproduce at 43fc130. Compiled a document whose only path to an Args-bearing model is ResponseStream.Events, under an operation with a GraphQL binding: pass.Validate returns no diagnostics, so no false positive fires.

graphqlReachableTypes now seeds its queue from a reflection walk over the operation rather than the hand-written walkOperationRefs this issue was filed against, and that walk reaches ResponseStream.Events.

Naming the site rather than generalising: only the ResponseStream.Events shape was probed. The other two this issue mentions — a model reachable solely through a Property.Args parameter type, and template instantiation args — were not tested and may still hold. Worth re-checking those two before closing.