fix(scala): walk type_definition right-hand sides for type references

[mdshzb04]

Fixes #2049

type_definition nodes (plain aliases, opaque type, match types) sit at the exact same template_body sibling level as val_definition/var_definition, but the Scala-specific dispatch in _extract_generic only fired for the latter — so alias right-hand sides produced zero references edges of any kind, as reported.

Changes

Two small edits in graphify/extractors/engine.py:

1. Widen the dispatch to include type_definition. Verified against tree-sitter-scala that the RHS lives under the same type field a val/var annotation uses (for plain aliases, opaque type, and match types alike), so the existing walk is reused verbatim — exactly the one-line widening the issue suggested.
2. Teach _scala_collect_type_refs about match_type / type_case_clause. As the issue predicted, the dispatch alone isn't enough for match types: the walker's recursion whitelist didn't know these node types, so a correctly-dispatched match-type RHS still resolved nothing. Adding them to the existing recursion tuple lets case patterns and results resolve.

Before / after

class Repo {
  type Alias = List[Int]
  opaque type Id = Long
  type Elem[X] = X match { case String => Char; case Array[t] => t }
}

Before: Repo has no outgoing references edges.
After: references edges to List, Int, Long, String, Char, Array, t, X — matching what an equivalent val annotation already produced.

Tests

Extended tests/fixtures/sample.scala with a TypeAliases class covering all three shapes, plus four new tests asserting the alias (Map/HttpClient), opaque (Long), and match-type case (Option/ListBuffer) references. Full run: tests/test_languages.py + tests/test_builtin_global_type_refs.py → 324 passed, 13 skipped.

Out of scope (kept separate deliberately): file-scope/trait containers (#2042, #2054) and qualified stable_type_identifier names (#2055) — this PR only closes the type_definition dispatch gap so it composes cleanly with fixes for those.

[IskandarovFirdavs]

Looks good overall. Could you briefly explain why True is passed here instead of using the existing generic variable? It would help future readers understand the intent.

[mdshzb04]

This line is pre-existing and only appears as context in this diff. It’s where the walker descends into the children of a type_arguments node, so everything below that point is in generic-argument position regardless of the outer generic value. Wrapper nodes instead pass generic through unchanged since they don't change that context.

[IskandarovFirdavs]

This change seems reasonable. Would adding a short comment above this condition make the special handling for Scala type references easier to understand?

[mdshzb04]

Good point. There’s already a comment just inside the condition explaining the type_definition handling, but I agree it would be clearer above the condition. I’ll move it there.

[IskandarovFirdavs]

Nice improvement. Have you tested this against nested or more complex Scala type definitions to ensure there are no regressions?

[mdshzb04]

Yes. The committed fixture covers nested type arguments with Map[String, HttpClient] and match-type cases with type-variable binding. I also tested deeper nesting locally with Map[String, List[Option[HttpClient]]] and a match type over Either[Throwable, Vector[Int]]; references resolved correctly at each depth. The full relevant test suite also passes with 324 passed and 13 skipped. Happy to add the deeper-nesting case to the fixture if you'd like it covered explicitly.