fix(deps): body-parser 2.2.2 → 2.3.0, clearing GHSA-v422-hmwv-36x6

[y1o1]

Summary

GHSA-v422-hmwv-36x6 — an invalid limit value silently disables size
enforcement, so a request body is accepted unbounded. Low severity, but the
dependency sits under auth-provider, which the provin.oss quickstart runs as
its front door.

vulnerable:  >= 2.0.0, < 2.3.0      patched: 2.3.0
was:         body-parser@2.2.2
now:         body-parser@2.3.0

Nothing upstream had to move

This was tracked as "waiting on @o3co/auth-provider-core's express pin".
That was wrong twice over:

1. @o3co/auth-provider-core declares express as a peerDependency
   (^5.0.0) — the consumer picks the version, not the library.
2. express@5.2.1 already allows body-parser: ^2.2.1, and 2.3.0 is a member
   of that range. The lockfile was simply holding a resolution from before
   2.3.0 was published.

pnpm update body-parser --recursive was the entire fix.

Two commits, deliberately

commit	what
89aa726	ordering only. pnpm install --lockfile-only with no dependency edit rewrites 48 lines — the committed file was written in an ordering the pinned pnpm no longer produces. Proven to be ordering alone: sorting both versions line-by-line yields byte-identical files, so nothing resolved differently.
this one	the actual change — 28 lines, all of them body-parser and its own dependency edges (content-type 1.0.5→2.0.0, type-is 2.0.1→2.1.0, +media-typer)

Splitting them keeps the security fix reviewable instead of buried under churn
that would otherwise ride along with any future lockfile touch.

Verified, not assumed

• grep body-parser pnpm-lock.yaml → only 2.3.0 remains.
• A from-scratch install (rm -rf node_modules) materializes exactly one
  copy. The first check showed two — a stale .pnpm directory the incremental
  install had not pruned, which would have read as "the fix did not take".
• Full workspace build + test: 507 tests across 7 packages, green.

🤖 Generated with Claude Code