Pin @asyncapi/specs to 6.11.1 (supply chain attack in 6.11.2)

[joostfarla]

Why

On 2026-07-14, @asyncapi/specs@6.11.2 and 6.11.2-alpha.1 were published with malicious
code injected via a compromised release pipeline (asyncapi/spec-json-schemas#656). The
payload executes on import (not via install scripts): it installs a persistent remote
access tool and exfiltrates credentials (npm/GitHub tokens, SSH keys, AWS credentials).

This repo depends on @asyncapi/specs transitively: @stoplight/spectral-rulesets
declares ^6.8.0 on it. Our committed lockfile already pinned the last clean release
(6.11.1) and CI installs with --frozen-lockfile, so no build here was compromised. But
while the malicious version was tagged latest, any un-frozen re-resolution (a dependency
bump touching the Spectral subtree, or a fresh resolve without the lockfile) would have
pulled it in.

What

• Pin @asyncapi/specs to exactly 6.11.1, in both dialects so the pin holds regardless
  of which package manager runs the install:
  • pnpm.overrides, read by pnpm (our toolchain and CI)
  • top-level overrides, read by npm and Bun; ignored by pnpm, so the two coexist
• Bump the patch version to 1.1.5 for release.

The lockfile diff is only the recorded overrides section; no other resolution changed.

Scope and current status

Overrides apply only at the root of an install, so this protects builds of this repo (and
the artifacts CI builds from it), not consumers who install the published package.
Package managers deliberately ignore overrides declared inside dependencies.

Consumers are protected by the registry cleanup instead: npm has since removed both
malicious versions entirely (6.11.2 and 6.11.2-alpha.1, including the alpha dist-tag)
and latest points to 6.11.1 again, so nothing malicious is reachable by any range, tag,
or exact version. This pin remains as defense-in-depth against a repeat compromise and
should be removed once AsyncAPI ships a verified-clean release above 6.11.1.

After merge: tag v1.1.5 to trigger the publish workflow.