fix: make npm version safe to run in parallel across workspaces

[alaminrifat]

Running npm version in parallel across many workspaces (e.g. with xargs -P or ultra-runner) intermittently fails with EJSONPARSE, because one npm process can read a package.json that another process is writing at that moment.

There are two places where this race happens:

1. Config workspace-root detection (workspaces/config loadLocalPrefix): when the cwd is inside a workspace, it calls mapWorkspaces() on the root, which parses every sibling workspace's package.json. If any of them is mid-write, config load throws and the whole npm invocation fails before any command runs. This is deterministically reproducible: empty out one workspace's package.json and run any npm command from inside another workspace.
2. npm version itself: changeWorkspaces() runs setWorkspaces() (another full mapWorkspaces() pass over the monorepo) and then updateWorkspaces() (an Arborist reify at the root), even when the only selected workspace came implicitly from the cwd.

Changes:

• lib/commands/version.js: when the workspace is selected implicitly (cwd inside a workspace, no --workspace/--workspaces flags), bump only that workspace — no monorepo traversal, no root reify. Explicit --workspace/--workspaces behavior is unchanged.
• workspaces/config/lib/index.js: if the workspace map cannot be read during workspace-root detection, log a warning and fall back to treating the current prefix as a standalone project instead of failing the entire config load.

Verification:

• 40-workspace fixture, npm version patch --no-git-tag-version run with 12-way parallelism: 2/40 invocations failed before this change, 0/40 after, with every workspace bumped exactly once.
• New tests cover the implicit single-workspace bump (asserting a single libnpmversion call, no lockfile creation) and the corrupt-sibling scenario at both the command and config layers.
• Existing test/lib/commands/version.js and workspaces/config suites pass unchanged.

References

Fixes #9412