Language support: VB.NET (regex tier)

[conradcoffman]

Is your feature request related to a problem?

VB.NET files are not indexed today. On a .NET estate that mixes C# and VB, the
C# half resolves into the graph and the VB half is invisible, so call chains
and blast-radius queries stop at the language boundary rather than at a real
edge of the system.

Describe the solution you'd like

A regex-tier (tier 2) extractor claiming .vb, alongside abap.go /
apex.go / al.go. VB is keyword-delimited (Class/End Class,
Sub/End Sub), so block extents come from the existing
findKeywordBlockEnd helper in helpers_indent.go. No new shared helpers.

.aspx is out of scope. Web Forms markup is a separate concern from the VB
language, the way razor.go claims .razor/.cshtml separately from
csharp.go; nothing claims .aspx today and if it is wanted it belongs in
its own extractor.

Use case

MCP tools and CLI, same as any other language extractor: find_usages,
call-chain and blast-radius queries over mixed C#/VB .NET repositories, where
today the VB side contributes nothing to the graph.

For new language support:

• Language: VB.NET (Visual Basic .NET)
• Tree-sitter grammar available in go-tree-sitter: no. Also none in
  go-sitter-forest: no vb/vbnet/basic entry among the 170 forest
  imports in forest_registrations.go, and nothing in go.mod/go.sum. So
  tiers 1 and 3 are both unavailable and this has to be tier 2.
• Key constructs to extract: namespaces, classes / modules / structures /
  interfaces / enums, delegates, P/Invoke Declares,
  Sub/Function/Property/Event members, Imports,
  Inherits/Implements, and call sites. Interfaces carry Meta["methods"]
  for IMPLEMENTS inference.

---

Two things I would rather hear your view on before sending a branch, since
they are the parts most likely to draw an objection.

1. Node identity. I followed csharp.go (owner-qualified
File::Type.Member, constructors on Type.<init>) rather than the flat
filePath::name the other regex-tier extractors use, reasoning that VB and C#
share the .NET member model and get queried side by side in one store. On a
~196-file production VB estate the flat scheme collides on 179 of 2945
declarations (6.1%) across 113 name groups, mostly Sub New overloads and
same-named members of two classes in one file; owner-qualifying removes those.
If you would rather a regex-tier extractor stay consistent with its tier than
with the language it mirrors, that is a cheap change now and an expensive one
later.

2. A known ambiguity. VB uses ( for indexed property access as well as
invocation, so dt.Rows(0) is syntactically identical to a call and is
emitted as one. Resolving it needs type information the extractor does not
have, and a hardcoded accessor blocklist (Rows/Cells/Fields/...) felt too
framework-specific to be correct upstream. These edges resolve to
unresolved::<name>, so DefaultOriginFor classifies them text_matched
rather than ast_resolved and the ambiguity is expressed in the provenance
tier. Happy to take direction if you would prefer they be dropped or marked
speculative instead.

I have a working branch with tests (20 tests / 43 subtests), golangci-lint
clean against the pinned version, and no new failures in the
internal/parser/languages suite. Glad to open the PR if this is wanted, or
to drop it if VB is out of scope for the project.