build(deps): take @mnci/nx-python-pip 0.2.11, which stops publishing a stale wheel

[russoedu]

The other half of the release fix. 0.2.10 (already on main) stopped projects a release
never versioned from publishing at all. 0.2.11 stops the ones it did version from
publishing their predecessor alongside the real thing.

python -m build --outdir adds to dist/ rather than replacing it, and the publish step
uploads dist/*. A release builds each package twice — once in preVersionCommand, at the
on-disk version, and again after the bump — so both wheels sat in dist/ and twine sent
both. Because nx release is tag-only, the on-disk version is the scaffold 0.0.1 and
stays there for ever.

The last release on main proves it. Same run, same project:

nx run scanmate-ocr:build
  Successfully built scanmate_ocr-0.24.3.tar.gz and scanmate_ocr-0.24.3-py3-none-any.whl
nx run scanmate-ocr:nx-release-publish
  Uploading scanmate_ocr-0.0.1-py3-none-any.whl

That is what put a 0.0.1 release on PyPI for scanmate-ink, -align, -merge and
-seal (two of them a 0.0.2 as well), silently — --skip-existing reports an
already-published version as a warning and exits 0.

npm install dropped the four nested @emnapi entries under the wasm32-wasi resolver
bindings again (fifth time); restored, and npm ci re-verified.

Still outstanding, and not fixed by this

PyPI's new-project rate limit (429) is still blocking the first publish of
scanmate-extract, -ocr and -scan. These two fixes stop the wasted creation attempts
that were spending the quota, but the quota itself has to clear on PyPI's schedule.

🤖 Generated with Claude Code