fix(compat): method-param reorder severity follows passing style

[gjtorikian]

Summary

Method parameter sensitivity.order was being sourced from policy.constructorOrderMatters, conflating constructor positional semantics with method call-site semantics. For Ruby/Python/Elixir (which have constructorOrderMatters: true), this caused kwarg-only method reorders to be flagged as breaking even though callers literally cannot observe parameter declaration order.

Concretely, on workos/openapi-spec#23 the Ruby diff reported Authorization.list_resources: request_options moved 9→8 as breaking. But the method signature is def list_resources(before:, after:, ..., request_options:) — every param is a keyword arg. The only real break in that method is search: being removed.

Changes

• src/compat/ir.ts — method-param sensitivity.order now derives from passing style (only 'positional'), not policy.constructorOrderMatters.
• src/compat/classify.ts — position-change handler now branches on passing:
  • keyword (Ruby/Python/Elixir) → no change emitted
  • options_object (Node) → no change emitted
  • named (PHP/Kotlin/C#) → constructor_reordered_named_friendly (soft-risk)
  • positional (Go/Rust) → parameter_position_changed_order_sensitive (breaking)
• Constructors retain existing policy.constructorOrderMatters semantics — unchanged.
• 6 new tests in language-matrix.test.ts covering each passing style.

Test plan

• npm test — 1417 pass (6 new)
• npm run typecheck clean
• npm run lint / format clean
• Regenerate the openapi-spec PR diff report and confirm Ruby Authorization.list_resources no longer flags request_options moved 9→8 as breaking

🤖 Generated with Claude Code