Fix "add Windows assets to the packages" merge failure

[Copilot]

Summary

The pull request / build / add Windows assets to the packages job failed with:

error: OpenTok.Net.Maui.<version>.nupkg has no counterpart in .../artifacts/.win9-pass
error: OpenTok.Net.Maui.<version>.snupkg has no counterpart in .../artifacts/.win9-pass

build/AddWindowsAssets.sh loops over each id in build/packages.tsv and packs that one package's Windows heads into .win9-pass/.win10-pass, but it passed the whole artifacts/ directory as the primary to build/merge-packages.py. That script merges every package it finds in the primary, so on the OpenTok.Net iteration the OpenTok.Net.Maui packages already sitting in artifacts/ had no counterpart in the Windows pass directory, and the script exited 1.

Changes

• Stage only the current package's .nupkg/.snupkg from artifacts/ into a scratch .primary directory (file names come from the pass directory, so no version parsing is needed) and merge that against the two Windows passes back into artifacts/.
• Error out clearly if a Windows-packed file has no matching package in artifacts/, which is the real precondition — BuildNugets.sh must have run first at the same version.
• Clean up the new scratch directory in the existing rm -rf/trap paths.

Other package ids are now left untouched until their own loop iteration, so the merge is per package as intended.

Validation

• sh -n build/AddWindowsAssets.sh
• Simulated an artifacts/ directory containing both package ids plus single-id Windows pass directories, and ran the two merge steps: the packed id gained both -windows TFMs and the other id was left unchanged.

[sbokatuk]

@copilot checks still failing, continue fixing

[sbokatuk]

@copilot failed check, analyze this, and OpenTok.Net.Win repo where win exists, find a correct fix and apply

[Copilot]

@copilot failed check, analyze this, and OpenTok.Net.Win repo where win exists, find a correct fix and apply

Analysed the last run (30436209875). The pack and merge themselves now succeed — both packages come out with net8/net9/net10-windows10.0.19041, including the MSB3030s from OpenTok.Client's native payload, which are handled the way OpenTok.Net.Win handles them (ExcludeAssets="build" + PrivateAssets="none" on the Windows references, mirroring src/OpenTok.Net.Win/OpenTok.Net.Win.csproj), plus the dotnet/maui#32683 PRI workaround for MAUI's HybridWebView.js.

What failed was the extra workflow step I had added after the script: under -o pipefail, which the step's shell sets, unzip -l pkg | grep -q 'lib/net9.0-windows' returns 141 whenever grep -q matches early and exits before unzip finishes writing — unzip dies of SIGPIPE and that becomes the pipeline's status. Reproduced locally. It reported "no lib/net9.0-windows*/ assets" for a package that had them, and passed for the other only by luck of entry order.

Removed it in 6d0c2c1: build/AddWindowsAssets.sh already asserts the same thing, and more strictly — it reads the lib/<tfm>/ folders out of every merged package and fails if any carries no Windows assets.