Iceoryx2.Reactive references the net8.0 Iceoryx2.dll for every target framework

## Required information

**Operating system:**

* macOS 26 (Darwin 25.5.0), arm64
* `uname -a`: `Darwin 25.5.0 Darwin Kernel Version 25.5.0: Mon Apr 27 20:39:42 PDT 2026; root:xnu-12377.121.6~2/RELEASE_ARM64_T6031 arm64`
* Not platform-specific — this is MSBuild reference resolution and reproduces on any host.

**.NET version:**
`dotnet --version` → `10.0.101` (SDKs 9.0.200 and 10.0.101 installed)

**iceoryx2-csharp version:**
`main` branch @ c8e0571

**iceoryx2 native library version:**
`v0.8.1` (submodule adf3f51) — not implicated; this is a build-configuration defect with no native
involvement.

**Detailed log output:**

On `main` the build is warning-free, which is precisely the problem — the defect is silent. It
becomes visible with a `netstandard2.1` target added (as in #24), where
`Iceoryx2.Reactive.csproj::TargetFramework=netstandard2.1` emits 7 unresolvable conflicts:

```
warning MSB3277: Found conflicts between different versions of "System.Runtime" that could not be resolved.
There was a conflict between "System.Runtime, Version=4.1.2.0" and "System.Runtime, Version=8.0.0.0".
References which depend on "System.Runtime, Version=4.1.2.0"
[.../NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Runtime.dll].
References which depend on or have been unified to "System.Runtime, Version=8.0.0.0"
.../src/Iceoryx2/bin/Release/net8.0/Iceoryx2.dll <-- net8.0 assembly in a netstandard2.1 build
```

…and the same for `System.Linq`, `System.Collections`, `System.Console`, `System.ComponentModel`,
`System.Runtime.InteropServices`, `System.Threading.Thread`.

**Observed result or behaviour:**

`src/Iceoryx2.Reactive/Iceoryx2.Reactive.csproj:47` pins the `Iceoryx2` `ProjectReference`:

```xml

...
TargetFramework=net8.0

```

`SetTargetFramework` overrides MSBuild's nearest-TFM matching, so **every** target framework of
`Iceoryx2.Reactive` compiles against — and copies to its output directory — the **net8.0** build of
`Iceoryx2`, not its own:

| TFM | `Iceoryx2/bin/Release//Iceoryx2.dll` | `Iceoryx2.Reactive/bin/Release//Iceoryx2.dll` |
|---|---|---|
| net8.0 | `67c296abd6c1` | `67c296abd6c1` ✅ |
| net9.0 | `2dd619b2fa5c` | `67c296abd6c1` ❌ net8.0 |
| net10.0 | `c92900c379e5` | `67c296abd6c1` ❌ net8.0 |

(sha1, first 12 hex digits.)

No warning is emitted because net8.0 → net9.0/net10.0 assembly references unify forward. Two
consequences:

1. **CI publishes a mismatched artifact.** `.github/workflows/build.yml` uploads
`src/Iceoryx2.Reactive/bin/Release/` wholesale, so the `net9.0/` and `net10.0/` folders of the
`dotnet-build` artifact contain a net8.0 `Iceoryx2.dll` beside a net9.0/net10.0
`Iceoryx2.Reactive.dll`. Anyone consuming build output directly gets a mismatched pair.
2. **It hides target-framework-specific API divergence at compile time.** `Iceoryx2.Reactive` only
ever sees the net8.0 surface of `Iceoryx2`. If `Iceoryx2` ever exposes something under a TFM
guard, `Iceoryx2.Reactive` could not use it and — worse — would not fail the build; it would
fail at runtime.

The NuGet packages are **not** affected: `lib//` contains only `Iceoryx2.Reactive.dll` and the
nuspec declares `Iceoryx2` as a package dependency in every group, so a restored package always
pairs matching assemblies.

**Expected result or behaviour:**

Each target framework of `Iceoryx2.Reactive` references and copies the `Iceoryx2` build for that
same target framework.

**Conditions where it occurred / Performed steps:**

```console
$ git checkout main # c8e0571
$ cargo build --release --package iceoryx2-ffi-c
$ dotnet build Iceoryx2.sln -c Release

$ for t in net8.0 net9.0 net10.0; do
echo "$t own=$(shasum -a1 src/Iceoryx2/bin/Release/$t/Iceoryx2.dll | cut -c1-12)" \
"reactive=$(shasum -a1 src/Iceoryx2.Reactive/bin/Release/$t/Iceoryx2.dll | cut -c1-12)"
done
net8.0 own=67c296abd6c1 reactive=67c296abd6c1
net9.0 own=2dd619b2fa5c reactive=67c296abd6c1
net10.0 own=c92900c379e5 reactive=67c296abd6c1
```

Surfaced while reviewing #24, which adds `netstandard2.1` to both projects — netstandard2.1 does not
unify forward from net8.0, so the pin turns from silent into 7 × `MSB3277` there.

## Proposed fix

Delete the `` metadata and let MSBuild's nearest-TFM matching do its job. The
remaining metadata on that `ProjectReference Update` (`PrivateAssets`, `IncludeAssets`,
`ReferenceOutputAssembly`) is what generates the package dependency — the pin is not needed for
that.

Removal is preferable to threading `TargetFramework=$(TargetFramework)` through: pass-through
hard-fails if the two TFM lists ever diverge, whereas nearest-match degrades gracefully.

## Acceptance criteria

* [ ] Each `Iceoryx2.Reactive` target framework references and copies its own matching `Iceoryx2` build
* [ ] Solution builds with no new warnings
* [ ] `dotnet pack` still declares `Iceoryx2` + `System.Reactive` in every nuspec dependency group, and `lib//` still contains only `Iceoryx2.Reactive.dll`

Start at src/Iceoryx2.Reactive/Iceoryx2.Reactive.csproj:47 and inspect the Iceoryx2 ProjectReference metadata, then build the solution in Release mode. Remove the target-framework pin and verify that each net8.0, net9.0, and net10.0 output contains its matching Iceoryx2.dll without new warnings. Run dotnet pack and confirm the dependency groups and lib// contents still meet the acceptance criteria.

Written by the indexing model from the issue text.