Update dependencies:

[erikd]

Specifically rely on aeson >= 2.3.0.0 to avoid a DoS vulnerability in earlier versions:

  https://haskell.github.io/security-advisories/advisory/HSEC-2026-0007.html

Pre-submit checklist:

• Branch
  • Tests are provided (if possible)
  • Commit sequence broadly makes sense
  • Key commits have useful messages
  • Changelog fragments have been written (if appropriate)
  • Relevant tickets are mentioned in commit messages
  • Formatting, PNG optimization, etc. are updated
• PR
  • (For external contributions) Corresponding issue exists and is linked in the description
  • Targeting master unless this is a cherry-pick backport
  • Self-reviewed the diff
  • Useful pull request description
  • Reviewer requested

[erikd]

More fixes needed

[Unisay]

Thanks for the quick turnaround. The build side is solid: the plan resolves and Hydra is green on Linux and Darwin against aeson 2.3.0.0, so CI is off the vulnerable aeson.

One thing to sort out before merge. The aeson >= 2.3.0.0 constraint lives only in cabal.project, which isn't shipped to CHaP/Hackage. The libraries that depend on aeson still admit vulnerable versions: plutus-tx has aeson >=2.2, and plutus-core / plutus-ledger-api have no bound at all, so anyone building those from CHaP can still resolve aeson < 2.3.0.0. For the fix to reach downstream consumers per HSEC-2026-0007, the >= 2.3.0.0 lower bound should also go into the build-depends of the published aeson-using packages: plutus-tx, plutus-core and plutus-ledger-api are the ones consumed downstream, with plutus-conformance, cardano-constitution and plutus-benchmark worth doing for consistency.

Two smaller things I hit while checking the solver.

The four aeson allow-newer lines this PR adds (aeson-pretty, deriving-aeson, microstache, monoidal-containers against aeson) are already redundant against the new index-state. I removed each and re-solved cabal build all --dry-run under GHC 9.6 and 9.12: the plan resolves without them, and aeson still pins to 2.3.0.0 via the constraint. The resolved versions already admit aeson 2.3, so the four lines can go.

The new QuickCheck >=2.18 bound is applied unevenly. withNumTests only exists from QuickCheck 2.18, but several components that call it don't carry the bound: untyped-plutus-core-testlib, plutus-ir-test, plutus-ledger-api-testlib and plutus-ledger-api-plugin-test. It builds in-project because cabal pins one QuickCheck for the whole solve, but a standalone build of either public testlib could resolve an older QuickCheck and fail. Adding QuickCheck >=2.18 there, especially the two testlibs, makes the bounds match usage.

Nits: the title has a typo ("dependencues"), and the doc/docusaurus path change is unrelated to the bump if you'd rather keep this PR focused.

Specifics are in the inline comments.

[Unisay]

LGTM, thanks!