feat(asyncapi): update to AsyncAPI 3.1.0

[danielkocot]

Checklist

• Tests added / updated
• Docs added / updated

Does this PR introduce a breaking change?

• Yes
• No

This PR adds support for AsyncAPI 3.1.0.

[Patrycja-dz]

Hi @danielkocot - thanks for this - AsyncAPI 3.1 support is genuinely useful and the format/schema-selection wiring here is solid. Two things before merging:

1. This needs a rebase. develop already bumped @asyncapi/specs to an exact-pinned 6.11.1 in chore: pin @asyncapi/specs to 6.11.1 #3022 (landed after this PR was opened). This branch's package.json change (^6.8.0 → ^6.11.1) now conflicts, and if resolved by "take theirs" it would silently revert that pin back to a caret range. Could you rebase and drop the package.json/yarn.lock change from this PR entirely once you're on top of develop - the exact-pinned 6.11.1 is already there.

2. One question about the version-selection switch, not a blocker for this PR specifically, but worth being aware of. getSchema() (in asyncApiDocumentSchema.ts) and getSchemaValidator() (in asyncApiPayloadValidation.ts) both switch on the known minor formats (aas2_0...aas3_1) with no fallback case. That means a document declaring a future 3.x minor Spectral doesn't yet recognize (e.g. 3.2.0, whenever that ships) matches the major-version aas3 format - so structural rules still run - but hits none of the listed cases in either switch. getSchema()'s fallthrough means asyncapi-3-document-resolved/-unresolved silently validate against nothing; getSchemaValidator()'s fallthrough means asyncapi-3-payload skips message payload validation the same way. Both happen even for a badly malformed document, with no warning either way. This isn't new to your change - it's the same gap 3.1 documents were in before this PR added the aas3_1 case to both switches.

Given AsyncAPI's 3.x minors are meant to be additive/non-breaking (per the 3.1 release notes), would you be open to adding a fallback in this PR - default to the newest known 3.x schema when the specific minor isn't recognized - so this doesn't recur silently at 3.2?

Nice work overall!

[danielkocot]

Hi @Patrycja-dz, I will rebase and add a fallback regarding the version.

[danielkocot]

Good catch on the version fallback. While implementing it, I noticed one distinction: there currently is no asyncapi-3-payload rule in the built-in ruleset. asyncApiPayloadValidation is only wired to asyncapi-payload, which is restricted to aas2; asyncapi-3-payload-unsupported-schemaFormat is a separate rule and does not invoke that validator.
I kept the shared fallback in getSchemaValidator() for consistency and future use, but this PR does not activate v3 payload validation or introduce a new rule. The fallback has an immediate effect on the resolved/unresolved v3 document rules. Wiring dedicated v3 payload validation would be better handled separately because it changes the ruleset’s behavior and requires its own givens, documentation, and compatibility tests.