refactor: replace asyncapi-validator with custom AsyncApiValidator

[cd-rite]

Removes asyncapi-validator and its dependency chain (~160 packages including minimatch@3.1.2, CVE-2026-27904) in favor of a lightweight module that parses AsyncAPI 3.0 YAML with js-yaml and compiles AJV validators directly. Fixes sendError schema/code mismatch where data was sent as an object but the spec declared it as a string.

Adds unit tests for the new module and a CI workflow to validate AsyncAPI specs on changes to api/source/specification/.

In general, the fix is to add an explicit permissions block limiting the GITHUB_TOKEN to the least privileges needed. This workflow only checks out contents and runs a validation command; it does not write to the repo, issues, or pull requests. Therefore, contents: read (and nothing else) is sufficient.

The best minimal change without altering existing behavior is to add a permissions section at the workflow root (top level, alongside name and on). This will apply to all jobs, including validate_asyncapi, and avoids repeating the block per job. Concretely, in .github/workflows/api-spec-validation.yml, insert:

permissions:
  contents: read

between the existing on: block (ending at current line 15) and the jobs: key (current line 17). No additional imports or methods are needed; this is pure YAML configuration for GitHub Actions.

In general, the fix is to explicitly declare a permissions block that restricts the GITHUB_TOKEN to the least privilege required. For this unit test workflow, all steps only read repository contents and do not perform any write operations to GitHub resources, so contents: read at the workflow level is sufficient.

The best way to fix this without changing functionality is to add a root-level permissions section just under the name: line (before on:). This will apply to all jobs in the workflow, including unit-tests, unless overridden by a job-specific permissions block. No changes to the steps are required. The new block should be:

permissions:
  contents: read

This is sufficient because actions/checkout, actions/setup-node, and npm commands used locally do not require write access to the GitHub API. No imports or additional definitions are needed; only this YAML change in .github/workflows/unit-tests.yml.

In general, to fix insecure temporary file creation, avoid manually concatenating os.tmpdir() with a generated name and then writing to it. Instead, delegate to a library or API that creates the file atomically with secure permissions and returns an already-open file or its unique path. In Node.js, a common solution is the tmp package (or fs.mkdtemp for directories, combined with controlled file creation).

For this specific file, the best fix is to replace the tempSpec implementation so that it uses tmp.fileSync to securely create the temporary file. tmp.fileSync will create a unique file in the system temp directory with safe permissions, and return an object including the file’s name and a file descriptor. We then write the content to name instead of constructing the path ourselves. Concretely:

• Add import tmp from 'tmp' near the other imports at the top of test/unit/mocha/asyncApiValidator.test.js.
• Change tempSpec so that:
  • It calls tmp.fileSync({ postfix: '.yaml' }) to create the temp file.
  • It writes content to file.name (the secure, already-created file path).
  • It pushes file.name into tmpFiles for later cleanup.
  • It returns file.name.

No other behavior of the tests changes: they still get a path to a YAML file on disk containing the given content, and the afterEach cleanup still unlinks those files.