Fix splat target in multiple assignment losing its element type

[apiology]

This PR was written by Claude Code on behalf of @apiology.

A splat target in a multiple assignment loses its inferred type entirely:

class Repro
  # @param mutator [Array<Symbol, BasicObject>]
  # @return [void]
  def call(mutator)
    command, *args = mutator
    args.fetch(0)  # Unresolved call to fetch
  end
end

Cause: MasgnNode#process looks up the pin for each left-hand-side entry by matching its node location against existing local/instance-variable pins. For a splat entry (*args, parsed as s(:splat, s(:lvasgn, :args))), the code used the splat node's location (*args) instead of the inner assignment target's location (args). These never match, so args never gets a mass_assignment set on it and stays permanently untyped.

Fix:

• Unwrap :splat nodes to their inner assignment target before computing the lookup location (and skip anonymous splats, which have no target).
• Track whether an entry is a splat alongside its right-hand-side node and index.
• In BaseVariable#probe, a splat entry now collects the union of the source array's element parameter types and binds Array<...> of that union, rather than binding a single (and previously entirely absent) element type.

Non-splat multiple assignment (a, b = pair) is untouched — this repo's ComplexType::UniqueType#tuple? is currently disabled (hard-coded false, added deliberately in #1201 "Ignore literal values in type inference"), so positional/tuple-accurate element typing isn't implemented for any multi-assignment position, splat or not; that limitation is out of scope here.

Test plan:

• bundle exec rspec spec/pin/base_variable_spec.rb — new specs for splat and non-splat masgn cases
• bundle exec rspec — full suite, 0 failures
• bin/solargraph typecheck --level strong on repro — 0 problems (previously "Unresolved call to fetch")
• bundle exec rubocop on changed files — clean