fix: npm wrapper never enforces PDFMUX_MIN_VERSION on an already-installed pdfmux

[NameetP]

What

npm-wrapper/index.js's isPdfmuxInstalled() only checked that import pdfmux succeeds on whatever python3/python the wrapper resolves to — never that the resolved version meets the wrapper's own declared PDFMUX_MIN_VERSION (1.4.0). Replaced with getInstalledVersion() + versionAtLeast(), which reinstall/upgrade when the existing install falls short, exactly like the already-correct "not installed at all" branch.

Why

Reported as #10 ("MCP server mode produces garbled Korean text — Korean characters misrecognized as Chinese — while the CLI works correctly on the same PDF"). The reporter's own follow-up comment root-caused a quality difference inside a single process() call, but CLI and MCP call the identical process() function with the identical default (quality="standard") — there is no code-path divergence there to explain a result difference on the same file.

The wrapper's findPython() searches python3/python on PATH, which is not guaranteed to be the same interpreter/environment backing the user's own pdfmux CLI binary (a pip-installed console script can live in a venv that isn't first on PATH). If that other environment already had an older pdfmux importable, the old check accepted it outright — silently serving a stale, pre-fix version of the audit/OCR-trigger logic instead of the version the wrapper advertises installing (pdfmux[serve]>=1.4.0). Two installs of the same "verified extraction" product silently drifting apart is exactly the kind of inconsistency this product exists to rule out in its own distribution path.

Verified

• node -c npm-wrapper/index.js — syntax OK.
• Hand-tested versionAtLeast() against 7 cases including the "1.10.0 vs 1.9.0" string-vs-numeric trap (1.10.0 must compare greater than 1.9.0) — all pass.
• No existing test harness for npm-wrapper/ (plain JS, no deps, no test runner wired) — this PR doesn't add one; flagging in case a future PR wants to.

Not done here (scope)

• Not published to npm. npm view pdfmux-mcp version still serves 1.4.0 after this merges — publishing a new version is a Tier-2 founder action in this product's pipeline, same gate as cutting a PyPI release. Filed as a decisions-pending row for the founder's call, same pattern as the existing PyPI-1.8.8 release decision.
• I have not independently confirmed the reporter's exact two-environment setup (no access to their machine) — this fix closes a real, verifiable defect in the wrapper's own logic regardless of whether it's the full explanation for MCP server mode produces garbled Korean text (OCR fallback) while CLI works correctly on the same PDF #10; commented on the issue asking the reporter to check python3 -c "import pdfmux; print(pdfmux.__version__)" against their CLI's own pdfmux --version to confirm.

Closes (partially — pending reporter confirmation) #10.