Poetry package listing fails for nested/non-root pyproject.toml projects (`poetry show` runs with wrong cwd)

Nadie ha tomado este issue todavía.

### Environment
- vscode-python-envs version: 1.36.0
- OS: Linux (devcontainer, linux-arm64)
- Poetry: 2.4.3

### Description
When a Poetry project is registered via `python-envs.pythonProjects` but is **not** at the workspace root (e.g. a monorepo with `scripts/pyproject.toml`), the "Manage Packages" package listing fails with:

```
poetry: Poetry could not find a pyproject.toml file in or its parents
```

### Root cause (found in source)
`PoetryPackageManager.getDirectPackageNames()` (`src/managers/poetry/poetryPackageManager.ts`) builds `PoetryShowTopLevelCommand` without ever passing a `cwd`:

```ts
const showTopLevelCmd = new PoetryShowTopLevelCommand({
pythonExecutable: poetry,
log: this.log,
});
```

This means `poetry show --no-ansi --top-level` always inherits the extension host process's own cwd (in a remote/devcontainer setup this is the vscode-server install directory), not the project directory. This is confirmed intentional by the existing unit test `poetryPackageManager.unit.test.ts`: *"direct package listing inherits the process working directory"* asserts `runPoetryStub.firstCall.args[1] === undefined`.

`fetchPackagesFromTool()` (used for plain `poetry show --no-ansi`) does compute a cwd via `getPoetryCwd()`, but that logic only reliably resolves when `api.getPythonProjects()` returns exactly one project. Since VS Code always implicitly adds the workspace root as a project (`PythonProjectManagerImpl.getInitialProjects()`), any repo with a registered non-root Poetry project (e.g. `scripts/`) ends up with 2+ projects, forcing the "match by environment identity" branch — which can return an empty `matchingDirectories` set (and thus `undefined` cwd) depending on how the workspace-root's own resolved environment compares.

### Repro
1. Monorepo with `pyproject.toml` only in a subfolder, e.g. `scripts/pyproject.toml`.
2. Add to `.vscode/settings.json`:
```json
"python-envs.pythonProjects": [
{ "path": "scripts", "envManager": "ms-python.python:poetry", "packageManager": "ms-python.python:poetry" }
]
```
3. Open "Manage Packages" for the `scripts` project's Poetry environment.

### Expected
`poetry show` commands run with cwd set to the registered project directory (`scripts/`).

### Actual
Both `poetry show --no-ansi --top-level` and `poetry show --no-ansi` fail with "could not find a pyproject.toml", repeating every time `packageWatchers` triggers an auto-refresh.

### Suggested fix
- Pass `cwd` (resolved from the project associated with `environment`, e.g. via `api.getPythonProject(environment.environmentPath)` or similar) into `PoetryShowTopLevelCommand` in `getDirectPackageNames()`.
- In `getPoetryCwd()`, prefer resolving cwd from the actual project that owns the environment (e.g. via reverse lookup by environment path) rather than only matching by `envId.id` equality across all projects.

Comienza en src/managers/poetry/poetryPackageManager.ts, especialmente en getDirectPackageNames() y getPoetryCwd(), y después lee poetryPackageManager.unit.test.ts y su aserción existente sobre el directorio de trabajo del proceso. Sigue cómo se resuelven el proyecto registrado y el entorno para proyectos anidados. Estará terminado cuando ambos comandos poetry show utilicen el directorio del proyecto registrado y las pruebas unitarias cubran ese comportamiento de cwd.

Escrito por el modelo de indexación a partir del texto del issue.