body-parser@1.x pins qs to "~6.15.1", blocking security patch releases like 6.16.0

## Summary

`body-parser@1.20.6` (the latest 1.x release) depends on `qs` with the tilde range `~6.15.1`, which only allows `qs` versions `>=6.15.1 <6.16.0`. This prevents npm from resolving newer patch/minor `qs` releases — including `6.16.0`, which contains several fixes (e.g. enforcing `arrayLimit` on comma groups, fixing `stringify`'s cycle detection on empty arrays) that are relevant for consumers who depend on `qs` for security-sensitive parsing.

Since `body-parser@1.x` is still the dependency used by `express@4.x` (which remains widely deployed and is not yet EOL), any `qs` release that isn't `6.15.x` is unreachable for `express@4` users without forcing an `overrides`/`resolutions` entry, or upgrading to `express@5` (which pulls in `body-parser@2.x`).

## Impact

When a security advisory affecting `qs` versions below some fixed version (e.g. `qs < 6.16.0`) is published, tools like Dependabot/Renovate cannot resolve the fix within the `body-parser@1.x` / `express@4.x` tree, because `~6.15.1` structurally excludes it. This forces either:
- an unwanted, unrelated major bump to `express@5`, or
- manual `overrides`/`resolutions` hacks in downstream `package.json` files to bypass body-parser's own declared range.

## Suggested fix

Relax the dependency range in `package.json` from:
```json
"qs": "~6.15.1"
to a caret range that still stays within qs's own semver-minor-compatible API surface, e.g.:
"qs": "^6.15.1"
(or otherwise widen it enough to allow future 6.x patch/minor releases), and cut a new 1.20.x (or 1.21.0) release with the change.

Environment

- body-parser version: 1.20.6 (latest 1.x)
- qs version affected: 6.16.0 (currently unreachable)

[]