Fix order-dependent generic resolution for same-class union receivers

[apiology]

Summary

Fixes #1272.

Chain::Call#resolve looks up a method pin per union member via binder.each_unique_type, then deduped the results with pin_groups.flatten.uniq(&:path). When a receiver's declared type unions multiple instantiations of the same generic class (e.g. Box<Integer>, Box<String>), both members resolve to a pin with the same path (Box#get) but each pin's return_type has already been correctly resolved for its own context (Integer vs String, respectively - this resolution happens earlier, inside ApiMap#get_method_stack). Deduping on path alone discarded every member but whichever happened to be listed first, so the inferred type depended on declaration order instead of being a real union.

The fix dedups on [path, return_type.tag] instead of path alone, so distinctly-resolved pins from different union members are preserved.

# @generic T
class Box
  # @return [generic<T>]
  def get; end
end

# @param b [Box<Integer>, Box<String>]
def process(b)
  b.get # now infers `Integer, String` regardless of declared union order
end

Test plan

• Added a regression test in spec/source/chain/call_spec.rb that checks both declaration orders resolve to the same union {Integer, String}
• bundle exec rspec - full suite green (0 failures)
• bundle exec rubocop - clean (pre-existing unrelated offenses left untouched)
• bundle exec solargraph typecheck --level strict lib/solargraph/source/chain/call.rb - 0 problems