…9019

withVersions() and the install script each expanded a module's declared version
ranges into the set of versions/<name>@<key> folders to test and install, and the
two computations had drifted — a folder could be installed but never tested, or
tested but never installed. A single resolvePluginVersions now drives both, so the
installed set and the tested set cannot diverge.

Per declared range the resolver pins the lowest supported version exactly, fills
each in-between major with a bounded >=N.0.0 <N+1.0.0 key, and keeps the declared
range itself as the top key. Keying the top by the range (not a bare major) is what
keeps a capped range capped: microgateway-core >=2.1 <=3.0.0 resolves to 3.0.0, not
the 3.3.7 a bare-major 3 key would pull in — a version the instrumentation does not
support, which had it emitting web.request instead of microgateway.request.

Generating the whole versions/ tree is thousands of mkdir/writeFile calls; an
unbounded Promise.all over the tree exhausts file descriptors (EMFILE). A
bounded-concurrency worker pool caps in-flight work, preserves input order, and
stops scheduling once any worker fails.

Expanding to every major surfaced real per-major gaps, fixed alongside:

1. restify runs the 4-6 and 10+ majors with async-only routing gated.
2. knex 1.x installs the @vscode/sqlite3 fork its dialect needs.
3. grpc's invalid.proto is proto2 so the required-field decode error survives loadSync.
4. hapi covers 16.x and 21+ and skips the EOL 19/20 majors that hang CI.
5. elasticsearch tolerates the util._extend deprecation the legacy client emits.
6. express-mongo-sanitize pins the <5 express folder it supports.
7. tedious BulkLoad row-stream listeners run in the caller's span, with bulkload specs adjusted for the >=13 shards.

The resolver fills in-between majors on its own, so the lodash, ws, and mquery
same-name externals that only re-stated their addHook ranges are dropped. Two
peer-dependency anchors replace them: @apollo/server pins graphql so v5 does not
resolve the 15.x apollo-server v3 drags in, and knex installs the @vscode/sqlite3
fork.

…9019

withVersions() and the install script each expanded a module's declared version
ranges into the set of versions/<name>@<key> folders to test and install, and the
two computations had drifted — a folder could be installed but never tested, or
tested but never installed. A single resolvePluginVersions now drives both, so the
installed set and the tested set cannot diverge.

Per declared range the resolver pins the lowest supported version exactly, fills
each in-between major with a bounded >=N.0.0 <N+1.0.0 key, and keeps the declared
range itself as the top key. Keying the top by the range (not a bare major) is what
keeps a capped range capped: microgateway-core >=2.1 <=3.0.0 resolves to 3.0.0, not
the 3.3.7 a bare-major 3 key would pull in — a version the instrumentation does not
support, which had it emitting web.request instead of microgateway.request.

Generating the whole versions/ tree is thousands of mkdir/writeFile calls; an
unbounded Promise.all over the tree exhausts file descriptors (EMFILE). A
bounded-concurrency worker pool caps in-flight work, preserves input order, and
stops scheduling once any worker fails.

Expanding to every major surfaced real per-major gaps, fixed alongside:

1. restify runs the 4-6 and 10+ majors with async-only routing gated.
2. knex 1.x installs the @vscode/sqlite3 fork its dialect needs.
3. grpc's invalid.proto is proto2 so the required-field decode error survives loadSync.
4. hapi covers 16.x and 21+ and skips the EOL 19/20 majors that hang CI.
5. elasticsearch tolerates the util._extend deprecation the legacy client emits.
6. express-mongo-sanitize pins the <5 express folder it supports.
7. tedious BulkLoad row-stream listeners run in the caller's span, with bulkload specs adjusted for the >=13 shards.

The resolver fills in-between majors on its own, so the lodash, ws, and mquery
same-name externals that only re-stated their addHook ranges are dropped. Two
peer-dependency anchors replace them: @apollo/server pins graphql so v5 does not
resolve the 15.x apollo-server v3 drags in, and knex installs the @vscode/sqlite3
fork.

Key each expanded major by its bare major (`versions/mongodb@3`) instead of a
bounded range (`versions/mongodb@>=3.0.0 <4.0.0`). The bare major reads cleanly
as a folder name and covers each major's latest, including the floor major's,
which the range form dropped. Follows the shared resolver from #9019.

Widening the matrix to every major's latest surfaced several latent failures:

1. A bare-major key resolves to that major's newest version, so a range ending
   inside its top major overshoots: microgateway-core `>=2.1 <=3.0.0` keyed `3`
   installed 3.3.7 and the span came back `web.request` instead of
   `microgateway.request`. The top major keeps the declared range whenever it
   stops short of the major's ceiling; fully-spanned and lower majors stay bare.
2. `versions/ai@4` and `@langchain/core@0` resolve to versions that have no VCR
   cassette and would hit the live API (401). A central `brokenVersions`
   registry drops a matching resolved version and surfaces the reason as a
   pending test, each entry a stop-gap carrying a TODO.
3. A manifest carrying a `workspace:` protocol dependency was copied verbatim
   into a generated workspace, so yarn failed with "Couldn't find any versions
   for X that matches workspace:*". Fall back to the pinned compatible version.
4. The Apollo fetch-failure test gated the error span on `version > '2.3.0'`, a
   lexicographic compare that breaks once the key is bare (`'2' > '2.3.0'` is
   false). Compare the resolved version with `semver.gt`.
5. Single-digit keying renames folders that several specs hard-code by range
   (express, langchain, bedrock runtime, aws-sdk). The bedrock require threw
   after `agent.load` with no `agent.close`, leaving the Remote Config poll
   running and hanging the job to the 45-minute timeout; the others silently
   skipped suites. Point the requires at the renamed folders.

Key each expanded major by its bare major (`versions/mongodb@3`) instead of a
bounded range (`versions/mongodb@>=3.0.0 <4.0.0`). The bare major reads cleanly
as a folder name and covers each major's latest, including the floor major's,
which the range form dropped. Follows the shared resolver from #9019.

Widening the matrix to every major's latest surfaced several latent failures:

1. A bare-major key resolves to that major's newest version, so a range ending
   inside its top major overshoots: microgateway-core `>=2.1 <=3.0.0` keyed `3`
   installed 3.3.7 and the span came back `web.request` instead of
   `microgateway.request`. The top major keeps the declared range whenever it
   stops short of the major's ceiling; fully-spanned and lower majors stay bare.
2. `versions/ai@4` and `@langchain/core@0` resolve to versions that have no VCR
   cassette and would hit the live API (401). A central `brokenVersions`
   registry drops a matching resolved version and surfaces the reason as a
   pending test, each entry a stop-gap carrying a TODO.
3. A manifest carrying a `workspace:` protocol dependency was copied verbatim
   into a generated workspace, so yarn failed with "Couldn't find any versions
   for X that matches workspace:*". Fall back to the pinned compatible version.
4. The Apollo fetch-failure test gated the error span on `version > '2.3.0'`, a
   lexicographic compare that breaks once the key is bare (`'2' > '2.3.0'` is
   false). Compare the resolved version with `semver.gt`.
5. Single-digit keying renames folders that several specs hard-code by range
   (express, langchain, bedrock runtime, aws-sdk). The bedrock require threw
   after `agent.load` with no `agent.close`, leaving the Remote Config poll
   running and hanging the job to the 45-minute timeout; the others silently
   skipped suites. Point the requires at the renamed folders.

Key each expanded major by its bare major (`versions/mongodb@3`) instead of a
bounded range (`versions/mongodb@>=3.0.0 <4.0.0`). The bare major reads cleanly
as a folder name and covers each major's latest, including the floor major's,
which the range form dropped. Follows the shared resolver from #9019.

Widening the matrix to every major's latest surfaced several latent failures:

1. A bare-major key resolves to that major's newest version, so a range ending
   inside its top major overshoots: microgateway-core `>=2.1 <=3.0.0` keyed `3`
   installed 3.3.7 and the span came back `web.request` instead of
   `microgateway.request`. The top major keeps the declared range whenever it
   stops short of the major's ceiling; fully-spanned and lower majors stay bare.
2. `versions/ai@4` and `@langchain/core@0` resolve to versions that have no VCR
   cassette and would hit the live API (401). A central `brokenVersions`
   registry drops a matching resolved version and surfaces the reason as a
   pending test, each entry a stop-gap carrying a TODO.
3. A manifest carrying a `workspace:` protocol dependency was copied verbatim
   into a generated workspace, so yarn failed with "Couldn't find any versions
   for X that matches workspace:*". Fall back to the pinned compatible version.
4. The Apollo fetch-failure test gated the error span on `version > '2.3.0'`, a
   lexicographic compare that breaks once the key is bare (`'2' > '2.3.0'` is
   false). Compare the resolved version with `semver.gt`.
5. Single-digit keying renames folders that several specs hard-code by range
   (express, langchain, bedrock runtime, aws-sdk). The bedrock require threw
   after `agent.load` with no `agent.close`, leaving the Remote Config poll
   running and hanging the job to the 45-minute timeout; the others silently
   skipped suites. Point the requires at the renamed folders.