dir_scan.lua: injected test stub permanently pollutes the real scan() for the rest of the process #331

Bug

lua/neotest-java/util/dir_scan.lua's scan() function reassigns a module-level upvalue instead of using a local variable when a dependency override is injected:

local iter_dir = function(dir) ... end  -- module-level default, defined once at file load

local function scan(dir, opts, dependencies)
	opts = opts or {}
	dependencies = dependencies or {}
	iter_dir = dependencies.iter_dir or iter_dir  -- BUG: reassigns the module-level default!
	...
end

Because Lua's mini.test runs every spec file in the same process, the first test that injects a stub iter_dir (e.g. tests/unit/test_dir_scan_spec.lua, which injects a fake iter_dir that only understands a handful of hardcoded fake paths) permanently replaces the real filesystem-scanning implementation for every subsequent call to scan() for the rest of the test run — not just for that one test.

Impact

Any code that calls the real (non-stubbed) dir_scan.scan() in a test that runs after test_dir_scan_spec.lua will silently get wrong results (typically an empty result set, since the stub only recognizes its own fake paths), with no error — it just silently returns nothing.

How it was found

While implementing #317 (replacing plenary.nvim), util/detect_project_type.lua's fallback path was rewritten to reuse dir_scan.lua for its recursive scan. The new integration tests (real nested directories on disk) failed intermittently depending on test execution order — always returning "unknown" instead of the correct project type when run as part of the full suite, but working correctly when run in isolation. Root-caused to this upvalue-clobbering bug.

Fix

Already fixed in #330 (part of the plenary.nvim removal PR stack) by renaming the module-level default to default_iter_dir and using a proper local iter_dir = dependencies.iter_dir or default_iter_dir inside scan() instead of reassigning the outer variable.

Why this matters beyond the PR that found it

This bug predates the plenary.nvim work entirely and could affect any other test that happens to run after test_dir_scan_spec.lua and calls the real dir_scan.scan() without injecting its own stub — worth being aware of as a general test-isolation hazard in this file, even after #330 lands.