1. The debug launch config never receives PROJECT_ROOT_PATH

The unittest execution adapter sets PYTHONPATH, TEST_RUN_PIPE and
PROJECT_ROOT_PATH for the run path. The debug path, in convertConfigToArgs
(inferred to be src/client/testing/common/debugLauncher.ts; quoted from the shipped
out/client/extension.js, beautified), injects only two of them:

p.env = {
  ...p.env,
  TEST_RUN_PIPE: n.pytestPort,
  RUN_TEST_IDS_PIPE: n.runTestIdsPort
};
const d = u.join(h.EXTENSION_ROOT_DIR, "python_files");
if (p.env) {
  const e = [d];
  p.cwd ? e.push(p.cwd) : n.cwd && e.push(n.cwd), (0, T.addPathToPythonpath)(e, p.env.PYTHONPATH)
}

Two defects here:

• PROJECT_ROOT_PATH is never added.
• addPathToPythonpath(...) is a pure function that returns the joined path, but its
  return value is discarded, so PYTHONPATH is never set either.

Only the first causes the symptom reported here. execution.py inserts the resolved cwd
onto sys.path itself (L213-217), so imports still resolve without PYTHONPATH.

Verified by reading the resolved LaunchRequest from a debugpy log
(DEBUGPY_LOG_DIR): the debuggee's env contains RUN_TEST_IDS_PIPE and
TEST_RUN_PIPE but neither PROJECT_ROOT_PATH nor PYTHONPATH. Confirmed across
three separate debug sessions.

2. Discovery and execution then disagree on top_level_dir

python_files/unittestadapter/discovery.py (L144-150) overrides top_level_dir with
PROJECT_ROOT_PATH:

project_root_path = os.environ.get("PROJECT_ROOT_PATH")
if project_root_path:
    top_level_dir = project_root_path

python_files/unittestadapter/execution.py does not - it uses -t (default None, per
pvsc_utils.parse_unittest_args) and additionally replaces start_dir with the resolved
cwd:

cwd = os.path.abspath(project_root_path or start_dir)
...
start_dir = cwd
suite = loader.discover(start_dir, pattern, top_level_dir)

So for -s ./test with no -t:

3. A mismatch produces silence rather than an error

execution.py's filter_tests matches on exact test.id() strings, and results are
streamed per test via UnittestTestResult -> send_run_data -> send_post_request. An
empty filtered suite therefore sends nothing at all, which is why the results pipe is
cancelled with no data and the test renders as "skipped" rather than as an error.

4. Why it is undiagnosable from the UI

The auto-generated test debug configuration resolves to console: internalConsole with
debugOptions: ["Multiprocess", "FixFilePathCase", "ShowReturnValue"] and no
RedirectOutput, so the adapter's stdout and stderr are discarded. Nothing appears in
the Debug Console, Terminal or Test Results. Adding "redirectOutput": true to a
launch.json config with "purpose": ["debug-test"] restores output.

Suggested fix

1. Propagate PROJECT_ROOT_PATH into the debug configuration's env alongside
   TEST_RUN_PIPE/RUN_TEST_IDS_PIPE.
2. Assign the result of addPathToPythonpath(...) back to p.env.PYTHONPATH.
3. Consider having execution.py honour PROJECT_ROOT_PATH as top_level_dir the way
   discovery.py does, so the two phases cannot disagree regardless of how the process
   is launched.
4. Consider defaulting redirectOutput to true for test debug sessions - the silence
   is what made this expensive to diagnose.

Note that (3) interacts with #26033, which is the opposite manifestation of the same
PROJECT_ROOT_PATH/-t coupling introduced by #25780: there, PROJECT_ROOT_PATH
overriding -t breaks discovery when the start directory is not importable from the
workspace root. A fix should probably reconcile both - honour an explicit -t when
given, and otherwise apply PROJECT_ROOT_PATH consistently in both phases and both
launch paths.