`pnpm add pypi:<package>` built `<dir>/pyproject.toml` unconditionally and
handed it to `manifest::add`, which read it with a bare `.into_diagnostic()?`.
At a workspace root without a root `pyproject.toml` the whole diagnostic was
`No such file or directory (os error 2)`: no path, no hint at what was
missing.
`plan_add` now checks for the manifest before it builds the install task, the
way the `crate:` counterpart in `cargo_deps::add::plan` already does, and
reports the path it looked for along with a help line pointing at a directory
that has a `pyproject.toml`. Checking at plan time also keeps the failure
ahead of the interpreter and the lockfile, so nothing is written.
The check is `try_exists` rather than `is_file`, which answers false for
every manifest that is not a regular file and not just an absent one. A
`pyproject.toml` that is a directory, or one whose metadata cannot be read,
keeps the error the filesystem gave.
The two reads that could still surface an unlabeled OS error now carry
`read {path}` context, matching `read_project_manifests`.
Related to pnpm/pnpm#14945 (item 11).
