shellFor: route through buildPackages so cross targets evaluate
`shellFor` (both v1 and v2) ran into "no C compiler provided for this platform" under cross targets where the host stdenv has no cc — most visibly ghcjs, also wasm and android-prebuilt. Three distinct issues, all fixed here: 1. `mkShell` itself was `pkgs.mkShell` (host-stdenv-bound). `pkgs.bashInteractive`'s eval reads `stdenv.cc.isClang`, and under ghcjs cross there is no cc → throw. Pass `mkShell = pkgs.buildPackages.mkShell` to both shellForV1 and shellForV2 so the shell drv lives on the build platform regardless of the host (the user opens the shell on their build host anyway). 2. `pkgs.runCommand` was building `packageEnv` and `wrappedGhc` (the wrapped GHC the shell exports as `shell.ghc`) against the cross stdenv. Once these landed in the shell's `nativeBuildInputs`, mkShell's dep-splicing eventually re-evaluated the cross stdenv's bash via setup hooks, hitting the same cc.isClang. Switch both to `pkgs.pkgsBuildBuild.runCommand` and `pkgs.pkgsBuildBuild.makeWrapper` so the wrappers themselves are build-platform drvs. (Native builds are unaffected — `pkgsBuildBuild == pkgs` there.) 3. `store = composedStore` was a top-level attr to mkShell. Recent nixpkgs's `mkDerivation` folds unknown top-level attrs into `env` and type-checks each value, and `isDerivation composedStore` forces evaluation of the cross stdenv's bash the same way. Move `store` into `passthru.store` — mkDerivation lifts passthru into the result drv anyway, so `shell.store` continues to resolve. Verified `tests.with-packages.test-shell` now evaluates under both the `aarch64-darwin.unstable.ghc9141.ghcjs` (cross) and `.native` jobsets, and `shell.store` still resolves on both.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?v=4&s=80)
![sg-doc-holiday[bot]](https://avatars.githubusercontent.com/in/1508860?v=4&s=80)