GeezerVison

The SwiftBuild backend's build directory doesn't encode the target triple, so
detect the traits derived from it by parsing the imports of the product binary
instead. The imports are now parsed as a part of the packaging build graph.

```
$ echo "@preconcurrency import var Foundation.stderr" | swiftly run +main-snapshot-2026-08-11 swiftc  - -o /dev/null
<stdin>:1:28: error: ambiguous name 'stderr' in module 'Foundation'
1 | @preconcurrency import var Foundation.stderr
  |                            `- error: ambiguous name 'stderr' in module 'Foundation'
2 |

Glibc.stderr:1:32: note: found this candidate
1 | nonisolated(unsafe) public var stderr: UnsafeMutablePointer<FILE>! { get }
  |                                `- note: found this candidate

/usr/include/stdio.h:151:14: note: found this candidate
149 | extern FILE *stdin;               /* Standard input stream.  */
150 | extern FILE *stdout;              /* Standard output stream.  */
151 | extern FILE *stderr;              /* Standard error output stream.  */
    |              `- note: found this candidate
152 | /* C89/C99 say they're macros.  Make them happy.  */
153 | #define stdin stdin
```

swiftlang/swift#89891

Flattening the tarball into /usr/local makes SwiftPM derive a bogus
toolchain root, so the swiftbuild build system cannot find swiftc.

Only memory imports were collected, so `WasmFeatures.isWASI` never saw
`wasi_snapshot_preview1` and the generated node.js dropped the WASI import
while still constructing a WASI instance.

…ystem

`swift package js test` assumed the native build system's single combined
`<Package>PackageTests` binary: it looked for one `.wasm`/`.xctest` under
`.build/<config>/`, packaged it, and ran it.

SwiftBuild produces no combined test binary. It emits one
`<TestTarget>-test-runner.wasm` per test target under `.build/out/Products/`,
plus an aggregate target that only orchestrates building them, so the old
lookup failed with "Failed to find 'JavaScriptKitPackageTests.wasm'".

(cherry picked from commit c12c7e9)

Because SwiftBuild mode produces a linked executable for each test
target.

(cherry picked from commit 0a1f926)

`js test` generates the glue from every test target's skeletons, but the
SwiftBuild build system links one binary per test target, so the eager
registration hit a missing export.

The per-runner `bridge-js.js` copied to the base output directory for test
preludes imports its JavaScript modules relative to itself, so copy the
`bridge-js-modules` directory next to it.

An imported type looked up from `getImports` contributes its static methods
too, but only a constructor marked the imports object as needed, so the glue
referenced an undeclared `imports`.

…nks in

`js test` generated the glue from every test target's skeletons and handed
the same copy to each SwiftBuild per-target runner, which described exports
those binaries don't have. Package the aggregated glue once into the shared
base directory, where preludes import it by a fixed path, and give each
runner glue scoped to the target it links in.

This supersedes the registration guard in the JS code generator.