v1.0.2

Security

• Peer floors raised to exclude known-vulnerable NestJS versions. The declared
  ranges were @nestjs/common ^11.0.0 and @nestjs/core ^11.0.0, and both
  admitted versions with published advisories:

  Peer	Advisory	Vulnerable	New floor
  @nestjs/common	GHSA-cj7v-w2c7-cp7c — remote code execution via the Content-Type header	>= 11.0.0-next.1, < 11.0.16	^11.0.16
  @nestjs/core	GHSA-36xv-jgw5-4q75 — improper neutralization of special elements in downstream output	<= 11.1.17	^11.1.18

  A peer range is a statement about which versions this library supports. Leaving
  the floor below a published advisory tells a consumer that a vulnerable install
  is a supported one, and nothing in their tooling contradicts it.

  Shipped as a patch, which is where a security fix belongs. Choosing a minor
  would have bought nothing: ^1.0.1 — what a consumer almost always declares —
  accepts 1.1.0 just as readily as 1.0.2, so the same installs are affected
  either way. Only a major would hold it back, and holding a security floor behind
  a major migration is the opposite of what it is for.

  No runtime behaviour changed, and the repository's own dev dependencies were
  already above both floors. A consumer below them sees a peer warning telling
  them to upgrade off a version with a published RCE advisory — which is the
  intended outcome, not collateral damage.

---