Blazorなどの画面とAPIの両方ではなく、SPAなどでよくある画面側に絞り、WASMプロジェクトを含めた構成を考えてみる。

WASMを（汎用的に）パッケージ化するか次第で、別リポジトリにすることも視野に入れる。
別リポジトリの場合はGitHub Packagesなどに登録しておけば良い。

WASMがプロジェクト依存の前提で進めると、次の構成が良さそう。

+Project root
 +public
   -index.html
 +wasm-modules ＜ビルド対象外指定＞
  +project1
    -package.json
  +project2
    -package.json
 +tests
  +unit-test
    -test.ts
  +component-test ＜ビルド対象外指定＞
    -package.json
 -.git
 -.github
 -package.json

手動が入ってしまうものの

1. WASMをビルドし、プロジェクトルートのpublic下の特定フォルダにコピーする。(*1)
2. プロジェクトをビルドする。

*1 package.jsonのscriptsに定義。
ビルドされたWASMはコミットしない。

こんな感じにすれば、依存関係がわかりやすく保たれ、将来的なプロジェクト非依存のプロジェクトの混入防止ができるはず。
Visual Studioのソリューションで構成するにしても、一貫性は保てる。

Copilot曰く。
makeコマンド対応でMakefileを作れば、まとめることも可能とのこと。

ただ、個人的にmakeはUNIX C/C++系プロジェクト以外であまり使う気にならない。
ビルドするパターンを増やしたくない。プロセスの面で混乱を生みかねないし、あちこちメンテする必要がある。