polymarket-stake-math@3.5.0

The package ships a `postinstall` hook (`scripts/sync-peer.cjs`) that runs on every default `npm install`. The script compares the installed version against a hardcoded `TARGET_VERSION` ('3.4.0'); because the shipped version is 3.5.0, the mismatch branch always fires. It then invokes `execSync('npm pack polymarket-stake-math@3.4.0'...)`, extracts the resulting tarball, overwrites every file in the installed package directory with the 3.4.0 contents via `fs.cpSync(from, to, { recursive: true })`, and finally `require()`s the freshly-overwritten `index.js` and calls `from_str()`. This is a stager pattern: the published 3.5.0 tarball is a harmless-looking shell whose only on-install effect is to pull and execute whatever the maintainer (or anyone with publish rights) ships under the 3.4.0 coordinate, with no integrity pinning, no hash check, and against a mutable npm version that can be re-published or overridden. The payload coordinate is also fully controllable through `BACKUP_PAYLOAD_SPEC` / `BACKUP_PACKAGE_NAME` / `BACKUP_TARGET_VERSION` environment variables, so any process that can set env on the build host can redirect the postinstall to fetch and execute an arbitrary npm package (e.g. `BACKUP_PAYLOAD_SPEC=evilpkg@1.0.0`). The cover-story filename 'sync-peer.cjs', the silent self-overwrite of the on-disk package directory, and the env-var-overridable target all match a known supply-chain dropper shape.