Return nil instead of raising NotImplementedError for def/lambda/block args

[rwstauner]

Fixes https://bugs.ruby-lang.org/issues/22129

ErrorHighlight.spot defaults point_type to :args for ArgumentError. When an
ArgumentError originates from argument binding (e.g. a missing required
keyword), its first backtrace location maps to a def/lambda/block node. The
spotter had no implementation for the :args point type on those nodes and did
raise NotImplementedError.

This is a regression from 0.7.0 (and in Ruby 4.0 compared to Ruby 3.4).

ErrorHighlight.spot only rescues SyntaxError/SystemCallError/ArgumentError, and
NotImplementedError is not a StandardError, so it escaped through
CoreExt#generate_snippet -> Exception#detailed_message / #full_message and
replaced the original exception. This is normally hidden because the VM's
"missing keyword" message matches the keyword regex in generate_snippet and
takes the safe :name branch, but it surfaces as soon as the ArgumentError is
re-raised/wrapped with a custom message that falls into the :args else branch.

Return nil (the documented "no spot" result) for these cases instead, matching
the graceful-degradation behavior of the surrounding feature. The fix is
applied consistently across both compilers:

• prism: def_node / lambda_node / block_node
• parse.y: DEFN / DEFS (raised NotImplementedError) and LAMBDA / ITER
  (silently returned a spot for :args, inconsistent with prism)

All of these branches were introduced together by the experimental "wrong
number of arguments" snippet feature and are only intended for point_type
:name, so returning nil for any other point_type keeps the two parsers in sync.

[mame]

Thanks, I agree this is the right call.

One thing on my mind: given that call_for_args spots the actual argument list, it feels natural that def_for_args would spot the parameter list. That said, in error_highlight as it stands today that feature would rarely be useful (unless you wrap an exception and rewrite its message, as you did here), so return nil seems sufficient for now. I might revisit the behavior in the future if a use case turns up.

Merging this, thanks again!