Memoize Reach.Project.Query.function_index/1

[jeroen11dijk]

Symptom

On a 4,700-line Elixir diff against a 146kLoC / 1,099-module project, mix reach.check --changed --base main doesn't complete in 20+ minutes. With this patch it completes
normally.

Root cause

Reach.Project.Query.function_index/1 rebuilds the full index on every call — four
Enum.group_by passes over project.nodes plus build_node_to_function_index/1. It's
invoked from multiple hot paths (find_function_at_location/3, find_function/2,
resolve_by_function_name/2, find_named_module/2). reset_cache/0 already existed as a
stub, and Reach.CLI.Project.load/1 already calls it on every project load — the caching
layer was clearly intended, just never wired up.

What this PR does

• Adds cache_key: reference() | nil to %Reach.Project{}, set via make_ref/0 in both
  terminal constructors (source_project/2, merge_project/2).
• function_index/1 memoizes in the process dictionary keyed on project.cache_key.
  Distinct projects carry distinct refs, so the existing isolation test ("function indexes do
  not leak between projects in the same process") still holds.
• reset_cache/0 deletes the cached entry.
• Adds positive memoization + reset tests alongside the existing isolation test.

Design notes (happy to revisit)

• Struct field vs explicit threading. Added a field rather than threading the index
  through callers because function_index/1 has many call sites across Query. The new field
  defaults to nil so existing pattern matches and constructions are unaffected, but it's
  still a minor-version change technically.
• Process dictionary vs ETS. Per-CLI-invocation scope matches process scope, and
  Reach.CLI.Project.load/1 already invalidates between loads. ETS would allow cross-process
  sharing but introduces lifecycle management that doesn't seem warranted yet — happy to
  switch if you'd prefer.
• Memory. The cached index is ~tens of MB for a 1k-module project. The CLI's existing
  Query.reset_cache() after each Project.load bounds it. Worth a moduledoc note if you
  want — happy to add.

Not in this PR (but worth a follow-up)

The deeper algorithmic issue is in Reach.Check.Changed.changed_functions/3 — it expands
every changed range to individual lines and calls find_function_at_location/3 per line:

ranges
|> Enum.flat_map(fn {first, last} -> first..last end)
|> Enum.map(&Query.find_function_at_location(project, file, &1))

[jeroen11dijk]

Furthermore mix reach.check --changed --base main gave low risk for this immense PR so Im unsure about its usefulness. Especially since something like it is nice for existing code bases with many violations already