fix(err): filter false-positive ExampleElement mutually exclusive resolver errors

[maruthang]

Description

Added an ExampleMutuallyExclusive error transformer that filters out false-positive resolver errors where apidom-reference incorrectly reports "ExampleElement value and externalValue fields are mutually exclusive" when only externalValue is present. The transformer is registered in the error transformer hook alongside the existing not-of-type and parameter-oneof transformers.

Motivation and Context

Fixes #10418

When a spec uses $ref at the path level and the referenced file contains examples with externalValue, the upstream apidom-reference library throws a false-positive mutual exclusivity error. This causes Swagger UI to display a spurious error message to users even though their spec is valid. This fix suppresses those false-positive errors at the error transformer layer, following the same pattern already used for other known false-positive errors.

How Has This Been Tested?

• Added 4 regression unit tests in test/unit/core/plugins/err/transformers/example-mutually-exclusive.js:
  • Filters out false-positive ExampleElement mutually exclusive resolver errors
  • Preserves non-resolver errors with the same message text
  • Preserves other resolver errors (e.g., network errors)
  • Correctly handles mixed errors (filters only the false-positive, keeps the rest)
• ESLint passes on all changed files

Screenshots (if appropriate):

N/A - no UI changes.

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.

[glowcloud]

Hi @maruthang, thanks for the PR. Unfortunately, I don’t think filtering out this error is the best solution. Instead, the error should be investigated and fixed in ApiDOM to address the root cause of the failure, rather than simply ignoring it.

[maruthang]

Thanks for the review @glowcloud — that's fair, filtering the symptom does leave the root cause in place. I'll dig into where the ExampleElement false-positive actually originates in ApiDOM and follow up there with a proper diagnosis (and a fix PR if I can pin it down).

[maruthang]

Followed up as promised: root cause diagnosed and fixed in ApiDOM — it's a double-traversal issue where the outer visitor re-visits an Example whose externalValue was already transcluded into value (with ref-origin meta) by the nested Path-Item-$ref pass, tripping the mutual-exclusion guard on the second visit. Details in swagger-api/apidom#5190, fix PR with regression tests: swagger-api/apidom#5191.