[wasm] Stale Emscripten 6.0.2 metadata is propagated to .NET 11 workload pack IDs while the toolchain uses 6.0.3

### Description

The .NET 11 WebAssembly workload currently appears to use Emscripten 6.0.3 as its effective toolchain version.

In an installed .NET 11 Preview 7 workload, `tools/emscripten/emscripten-version.txt` reports:

```text
6.0.3
```

and the `$(EmscriptenVersion)` MSBuild property exposed to consuming projects also resolves to:

```text
6.0.3
```

This part appears to be correct.

However, I noticed that Emscripten 6.0.2 still appears in multiple pieces of repository/build metadata, and this value appears to propagate into the actual workload artifacts.

For example, `dotnet/emsdk` currently contains:

https://github.com/dotnet/emsdk/blob/release/11.0/eng/Versions.props

```xml
6.0.2
```

There are also references to `6.0.2` in the `dotnet/runtime` repository:

https://github.com/search?q=repo%3Adotnet%2Fruntime+6.0.2&type=code

This is observable in the produced workload as well.

For example, on macOS arm64 the installed pack is named:

```text
Microsoft.NET.Runtime.Emscripten.6.0.2.Sdk.osx-arm64
```

even though the Emscripten toolchain contained in that pack reports:

```text
6.0.3
```

The .NET 11 Preview 7 artifact list similarly contains packages such as:

* `Microsoft.NET.Runtime.Emscripten.6.0.2.Sdk.osx-arm64`
* `Microsoft.NET.Runtime.Emscripten.6.0.2.Sdk.linux-x64`
* `Microsoft.NET.Runtime.Emscripten.6.0.2.Sdk.win-x64`

So this does not appear to be only a stale value in a repository file; the `6.0.2` identifier is propagated into the workload artifacts that users install.

For context, I previously contributed:

https://github.com/dotnet/emsdk/pull/1534

which allows consuming MSBuild projects to use the version from `emscripten-version.txt` as `$(EmscriptenVersion)`.

That mechanism currently returns `6.0.3`, which appears to be the correct value.

The problem is therefore not that `$(EmscriptenVersion)` is incorrect.

The issue is that different parts of the workload and its build metadata identify the same toolchain as either `6.0.2` or `6.0.3`, making it difficult for users and package authors to determine which Emscripten version is authoritative.

### Reproduction Steps

1. Install the .NET 11 Preview 7 SDK and the `wasm-tools` workload.
2. Inspect the installed Emscripten workload pack.
3. Inspect `tools/emscripten/emscripten-version.txt`.

### Expected behavior

There should be a clear and consistent way to identify the Emscripten toolchain version used by a .NET WebAssembly workload.

If Emscripten `6.0.3` is the effective toolchain version, I would expect metadata that represents the Emscripten toolchain version to consistently identify it as `6.0.3`.

In particular, it is currently unclear how the following values are intended to relate to one another:

* `dotnet/emsdk` `eng/Versions.props`: `EmscriptenVersion`
* `Microsoft.NET.Runtime.Emscripten..*` pack ID
* `tools/emscripten/emscripten-version.txt`
* MSBuild `$(EmscriptenVersion)`

If some of these values intentionally represent different concepts, it would be helpful to document what each version represents.

It would also be useful to clearly specify which value package authors should use when they need to determine the actual Emscripten toolchain version used to build/link WebAssembly native code.

### Actual behavior

The same .NET 11 Preview 7 workload currently exposes two different Emscripten version identifiers.

For example:

```text
dotnet/emsdk eng/Versions.props:
EmscriptenVersion = 6.0.2

Published / installed workload pack:
Microsoft.NET.Runtime.Emscripten.6.0.2.Sdk.osx-arm64

Installed tools/emscripten/emscripten-version.txt:
6.0.3

MSBuild $(EmscriptenVersion):
6.0.3
```

The `6.0.2` value also appears in `dotnet/runtime`, and appears to be used as part of the metadata from which the workload artifacts are produced.

As a result, a user inspecting the installed SDK sees a pack whose name indicates Emscripten `6.0.2`, while inspecting the toolchain inside that same pack indicates Emscripten `6.0.3`.

This makes it difficult to determine which version should be treated as authoritative.

### Regression?

I do not currently observe a build regression caused by `$(EmscriptenVersion)`, since that property correctly resolves to `6.0.3`.

However, the older `6.0.2` value appears to remain in build metadata and is propagated into the names/IDs of workload artifacts.

So while this may not currently cause a build failure, it produces externally visible inconsistent metadata.

### Known Workarounds

_No response_

### Configuration

.NET SDK / WebAssembly SDK:

```text
11.0.0-preview.7.26381.103
```

Installed Emscripten workload pack:

```text
Microsoft.NET.Runtime.Emscripten.6.0.2.Sdk.osx-arm64
11.0.0-preview.7.26381.103
```

OS:

```text
macOS
```

Architecture:

```text
arm64
```

Effective version reported by `emscripten-version.txt`:

```text
6.0.3
```

Effective MSBuild property:

```text
$(EmscriptenVersion) = 6.0.3
```

### Other information

Related PR:

https://github.com/dotnet/emsdk/pull/1534

That PR allows consuming projects to access the Emscripten version from `emscripten-version.txt` through `$(EmscriptenVersion)`.

That mechanism appears to behave correctly here and reports Emscripten `6.0.3`.

Relevant `dotnet/emsdk` metadata:

https://github.com/dotnet/emsdk/blob/release/11.0/eng/Versions.props

Relevant `dotnet/runtime` search:

https://github.com/search?q=repo%3Adotnet%2Fruntime+6.0.2&type=code

The important part of this issue is that the stale-looking `6.0.2` value is not limited to source repository metadata.

It appears in the IDs/names of the actual workload packs distributed with .NET 11 Preview 7.

This gives users conflicting information when trying to answer a relatively simple question:

> **Which Emscripten version does this .NET WebAssembly workload use?**

From `emscripten-version.txt` and `$(EmscriptenVersion)`, the answer appears to be:

```text
6.0.3
```

From `Versions.props` and the workload pack ID, the answer appears to be:

```text
6.0.2
```

If these values are intentionally different, clarification of their semantics would be useful.

Otherwise, it seems that the remaining `6.0.2` metadata should be updated so that the workload artifacts consistently identify the Emscripten version they actually contain.

Start with dotnet/emsdk release/11.0/eng/Versions.props and compare the 6.0.2 references found in dotnet/runtime. Reproduce by installing the .NET 11 Preview 7 wasm-tools workload, then inspect the pack ID, tools/emscripten/emscripten-version.txt, and MSBuild $(EmscriptenVersion). Done means the metadata consistently identifies the toolchain, or its differing version semantics are documented.

Written by the indexing model from the issue text.