[Doc] Add a lambda good example to Rake/MethodDefinitionInTask

[corsonknowles]

Summary

Adds a second # good example to the Rake/MethodDefinitionInTask documentation, showing a lambda assigned to a task-local variable as an alternative to hoisting the def to the top level.

The cop's full description today reads:

Detects method definition in a task or namespace, because it is defined to the top level. It is confusing because the scope looks in the task or namespace, but actually it is defined to the top level.

Its only # good example moves the def above the task. That's a valid fix, but not always the one you want: a top-level def becomes a method on Object, so it is visible everywhere and can silently collide with a same-named helper in another rake file (all .rake files load into a single process — last definition wins). A lambda bound to a local avoids both problems.

New example

# good - A lambda assigned to a local variable is scoped to the
#        block, so it is not defined at the top level.
task :foo do
  helper = -> { do_something }
  helper.call
end

Why this is genuinely "good" (and the closure nuance)

A def inside a task/namespace block attaches to the current definee, which at a rake file's top level is Object — blocks don't change the definee, which is exactly the confusion the cop names. Assigning helper = -> { ... } is a local variable assignment, which is lexically scoped to the block and never touches Object.

The nuance worth noting: the lambda's body still closes over the block's bindings, so it can freely use the task's locals and arguments — it is a closure over the task scope. But the name is a block-local, not a top-level method, so nothing leaks. A lambda's return also returns from the lambda (matching method semantics), so helpers that use early returns keep working.

Docs-only change; bundle exec rake (rubocop + spec) is green.

[koic]

Documentation-only changes don't need a changelog entry.

[corsonknowles]

Thanks @koic
Amended!