The LSP emits "▶ Run Test" / "Debug" code lenses above Deno.test calls (resolved by the deno.client.test command in the VS Code extension), but test steps only had the native test-explorer gutter "play" button — which can run a step but not debug it. This is the gap described in #21664.

Change

DenoTestCollector (in cli/lsp/code_lens.rs) now descends into test function bodies and emits the same "▶ Run Test" / "Debug" code lenses for each test step:

• t.step(...) on the test context, including arbitrarily nested steps
• destructured step(...) (e.g. Deno.test("t", ({ step }) => …))
• BDD it(...) / it.only|ignore|skip(...) inside describe(...)

The step-detection logic mirrors the static collector in cli/lsp/testing/collectors.rs (which already powers the test-explorer tree), reusing its parse_test_context_param helper.

Why filter by the parent test name

deno test --filter matches top-level test names only (TestFilter::includes is applied per top-level test; steps always run with their parent). So each step lens filters by its enclosing top-level test name. "Debug" on a step therefore runs its parent test under the inspector — exactly the same test the gutter "play" button already runs, but now with the debugger attached and the user free to set a breakpoint inside the step.

Top-level code lens output is unchanged (the existing test_deno_test_collector unit test and lsp_code_lens_test integration test are untouched).

Tests

Added unit tests in cli/lsp/code_lens.rs covering t.step, destructured step, and BDD it steps. Run with cargo test -p deno --lib lsp::code_lens.

Closes #21664

Closes denoland/divybot#436