chore(deps): bump path-to-regexp

[dependabot]

Bumps and path-to-regexp. These dependencies needed to be updated together.
Updates path-to-regexp from 8.3.0 to 8.4.0

Release notes

Sourced from path-to-regexp's releases.

8.4.0

Important

• Fix CVE-2026-4926 (GHSA-j3q9-mxjg-w52f)
• Fix CVE-2026-4923 (GHSA-27v5-c462-wpq7)

Fixed

• Restricts wildcard backtracking when using more than 1 in a path (pillarjs/path-to-regexp#421)

Changed

• Dedupes regex prefixes (pillarjs/path-to-regexp#422)
  • This will result in shorter regular expressions for some cases using optional groups
• Rejects large optional route combinations (pillarjs/path-to-regexp#424)
  • When using groups such as /users{/delete} it will restrict the number of generated combinations to < 256, equivalent to 8 top-level optional groups and unlikely to occur in a real world application, but avoids exploding the regex size for applications that accept user created routes

Commits

• 34cb451 8.4.0
• 22a9679 Reject large optional route combinations (#424)
• 8881a88 Byte optimization (#423)
• 43669ac Dedupe regex prefixes (#422)
• 4864654 Restrict repeated wildcard backtracking (#421)
• 05a5a97 Remove dependabot config (#404)
• 5b635cd Remove package-lock.json (#407)
• See full diff in compare view

Updates path-to-regexp from 0.1.12 to 0.1.13

Release notes

Sourced from path-to-regexp's releases.

8.4.0

Important

• Fix CVE-2026-4926 (GHSA-j3q9-mxjg-w52f)
• Fix CVE-2026-4923 (GHSA-27v5-c462-wpq7)

Fixed

• Restricts wildcard backtracking when using more than 1 in a path (pillarjs/path-to-regexp#421)

Changed

• Dedupes regex prefixes (pillarjs/path-to-regexp#422)
  • This will result in shorter regular expressions for some cases using optional groups
• Rejects large optional route combinations (pillarjs/path-to-regexp#424)
  • When using groups such as /users{/delete} it will restrict the number of generated combinations to < 256, equivalent to 8 top-level optional groups and unlikely to occur in a real world application, but avoids exploding the regex size for applications that accept user created routes

Commits

• 34cb451 8.4.0
• 22a9679 Reject large optional route combinations (#424)
• 8881a88 Byte optimization (#423)
• 43669ac Dedupe regex prefixes (#422)
• 4864654 Restrict repeated wildcard backtracking (#421)
• 05a5a97 Remove dependabot config (#404)
• 5b635cd Remove package-lock.json (#407)
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

[JiwaniZakir]

This updates two separate copies of path-to-regexp in package-lock.json: the top-level node_modules/path-to-regexp (0.1.12 → 0.1.13) and a nested copy under node_modules/router/node_modules/path-to-regexp (8.3.0 → 8.4.0). Since only package-lock.json is modified and not package.json, these are transitive dependency bumps — worth confirming whether this was generated via npm audit fix or similar, since it's not obvious from the PR what triggered the change or whether a CVE prompted it.

The presence of the 0.1.x line alongside the 8.x line is worth a second look: the 0.1.x branch is a very old legacy version with known ReDoS vulnerabilities in earlier releases, and having it silently nested in the tree is a latent risk. It would be worth tracing which package pulls in the 0.1.x dependency and checking if that parent dependency can be updated to pull in a modern version instead, rather than continuing to carry this ancient branch.

Finally, it's worth running the test suite after applying this lock file to confirm the router-dependent code paths still behave correctly, since the 8.3.0 → 8.4.0 bump in the router subtree could affect route matching behavior if there were any subtle semantics changes between those releases.