Discovery falls through to adapters when `requireVersion` doesn't match a native resource

[Gijsreyn]

Summary of the new feature / enhancement

When a configuration document pins a resource with requireVersion, and the requested type exists as a native command-based DSC resource, but no installed version satisfies the requirement, DSC unnecessarily falls through to full adapter discovery. The eventual error is non-specific, and the operation takes seconds, let alone minutes longer than it should.

To reproduce it from a fresh box, run the following configuration document with the latest DSC version:

# echo.dsc.config.yaml
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
- name: echo
  type: Microsoft.DSC.Debug/Echo
  requireVersion: '=0.1.0'
  properties:
    output: echo

Run: dsc config get --file echo.dsc.config.yaml.

Observation:

1. DSC finds Microsoft.DSC.Debug/Echo@1.0.0 in the native resource cache. =0.1.0 does not match 1.0.0, so the filter is left unsatisfied.
2. DSC then starts iterating every registered adapter
3. After the full sweep, the operation fails with a generic "resource not found" style error rather than a precise version-mismatch message.

What I would expect is that DSC recognizes the type as native and that the only reason the filter wasn't satisfied is the version constraint. DSC will then fail fast with a precise error like:

Resource Microsoft.DSC.Debug/Echo is installed at version(s) 1.0.0, but none satisfy =0.1.0.

Then the adapters don't have to be invoked.

Proposed technical implementation details (optional)

See the draft pull request attached.