Correct reference assembly mechanism in skills/instructions

Update copilot-instructions.md and the interop-generator and update-copilot-instructions skills to describe the actual mechanism used to build the WinRT.Runtime reference assembly: the WINDOWS_RUNTIME_REFERENCE_ASSEMBLY and WINDOWS_RUNTIME_IMPLEMENTATION_ASSEMBLY define constants, the [WindowsRuntimeImplementationOnlyMember] attribute (which triggers MSBuild file removal), the #define WINDOWS_RUNTIME_IMPLEMENTATION_ONLY_FILE opt-out, and the wholesale folder removals.

Co-Authored-By: Copilot <223556219+Copilot@users.noreply.github.com>

Author: Sergio0694

.github/copilot-instructions.md

@@ -167,7 +167,7 @@ The runtime library (`WinRT.Runtime.dll`) provides all common infrastructure for
 - **Warnings as errors**: release only. `EnforceCodeStyleInBuild` enabled, `AnalysisLevelStyle` = `latest-all`.
 - **Strong-name signed** with `key.snk`
 - **AOT compatible**: `IsAotCompatible = true`
-- **Reference assembly**: the project is built twice for NuGet packaging. With `CsWinRTBuildReferenceAssembly=true`, it produces a reference assembly (for `ref\net10.0\` in the NuGet) that strips all private implementation detail types and members via `#if !REFERENCE_ASSEMBLY`. The normal build produces the full implementation assembly (for `lib\net10.0\`). This replaces the previous approach of marking implementation details with `[Obsolete]` and `[EditorBrowsable(Never)]` attributes.
+- **Reference assembly**: the project is built twice for NuGet packaging. With `CsWinRTBuildReferenceAssembly=true`, it produces a reference assembly (for `ref\net10.0\` in the NuGet) that strips all private implementation detail types and members. The normal build produces the full implementation assembly (for `lib\net10.0\`) and defines `WINDOWS_RUNTIME_IMPLEMENTATION_ASSEMBLY`; the reference assembly build defines `WINDOWS_RUNTIME_REFERENCE_ASSEMBLY` instead. Stripping is driven primarily by the `[WindowsRuntimeImplementationOnlyMember]` attribute (a `[Conditional("WINDOWS_RUNTIME_REFERENCE_ASSEMBLY")]` marker on top-level types) plus an MSBuild target that removes any source file containing that attribute, any file with a top-of-file `#define WINDOWS_RUNTIME_IMPLEMENTATION_ONLY_FILE`, and entire implementation-only folders (e.g. `ABI\`, `NativeObjects\`, most `InteropServices\` subfolders). Method bodies remaining in the reference assembly are stubbed with `throw null`. This replaces the previous approach of marking implementation details with `[Obsolete]` and `[EditorBrowsable(Never)]` attributes.
 
 **Directory structure:**
 

.github/skills/interop-generator/SKILL.md

@@ -32,11 +32,11 @@ The `WinRT.Interop.dll` assembly is produced by `cswinrtinteropgen`, which is a
 - If a project **does not** reference CsWinRT, then `cswinrtinteropgen` is loaded from the Windows SDK projections targeting pack.
 - If CsWinRT **is** referenced (directly or transitively), then `cswinrtinteropgen` is loaded from that package, but only if the `WinRT.Runtime.dll` binary from that package has a higher version than the one in the Windows SDK projections package being referenced. This correctly handles cases where a dependent project might have a reference to an outdated CsWinRT package.
 
-This version matching is critical because `cswinrtinteropgen` relies on internal implementation detail APIs in `WinRT.Runtime.dll` — APIs which are public in the implementation assembly but excluded from the reference assembly (via `#if !REFERENCE_ASSEMBLY`), and which are exclusively meant to be consumed by generated code produced by `cswinrtinteropgen`. These APIs might change at any time without following semantic versioning for CsWinRT. For instance, they are crucial to support marshalling generic Windows Runtime collection interfaces, and the code in `WinRT.Interop.dll` makes heavy use of them in this scenario.
+This version matching is critical because `cswinrtinteropgen` relies on internal implementation detail APIs in `WinRT.Runtime.dll` — APIs which are public in the implementation assembly but excluded from the reference assembly (via the `[WindowsRuntimeImplementationOnlyMember]` attribute and related MSBuild stripping, controlled by the `WINDOWS_RUNTIME_REFERENCE_ASSEMBLY` / `WINDOWS_RUNTIME_IMPLEMENTATION_ASSEMBLY` define constants), and which are exclusively meant to be consumed by generated code produced by `cswinrtinteropgen`. These APIs might change at any time without following semantic versioning for CsWinRT. For instance, they are crucial to support marshalling generic Windows Runtime collection interfaces, and the code in `WinRT.Interop.dll` makes heavy use of them in this scenario.
 
 ### Private implementation detail APIs
 
-`WinRT.Runtime.dll` is shipped as two assemblies in the CsWinRT NuGet package: a **reference assembly** (in `ref\net10.0\`) that exposes only the versioned public API surface, and an **implementation assembly** (in `lib\net10.0\`) that contains the full set of types and members. Many types in the implementation assembly are "public" only because generated code in other assemblies (produced by `cswinrt.exe` and `cswinrtinteropgen`) needs to call them — they are not part of the stable API contract. These types are stripped from the reference assembly via `#if !REFERENCE_ASSEMBLY`, so consumers never see them.
+`WinRT.Runtime.dll` is shipped as two assemblies in the CsWinRT NuGet package: a **reference assembly** (in `ref\net10.0\`) that exposes only the versioned public API surface, and an **implementation assembly** (in `lib\net10.0\`) that contains the full set of types and members. Many types in the implementation assembly are "public" only because generated code in other assemblies (produced by `cswinrt.exe` and `cswinrtinteropgen`) needs to call them — they are not part of the stable API contract. These types are stripped from the reference assembly via the `[WindowsRuntimeImplementationOnlyMember]` attribute (a `[Conditional("WINDOWS_RUNTIME_REFERENCE_ASSEMBLY")]` marker that triggers an MSBuild target to remove the entire source file), an opt-in `#define WINDOWS_RUNTIME_IMPLEMENTATION_ONLY_FILE` directive at the top of a source file, or wholesale folder removals (e.g. `ABI\`, `NativeObjects\`, most `InteropServices\` subfolders), so consumers never see them. Method bodies that remain in the reference assembly are stubbed with `throw null`.
 
 The interop generator receives a reference to the **implementation** `WinRT.Runtime.dll` (not the reference assembly) so that it can resolve and emit calls to these internal APIs. Examples of private implementation detail types that the interop generator uses heavily include:
 

.github/skills/update-copilot-instructions/SKILL.md

@@ -26,7 +26,7 @@ Launch parallel explore agents for each of the 8 CsWinRT 3.0 projects listed in
    - Key types listed still exist and have the described purposes
    - T4 templates (`.tt` files) are accurately listed
    - Project settings (TFM, language version, nullable, unsafe, etc.) are current
-   - Reference assembly build setup (`CsWinRTBuildReferenceAssembly`, `#if !REFERENCE_ASSEMBLY`) is accurately described
+   - Reference assembly build setup (`CsWinRTBuildReferenceAssembly`, `WINDOWS_RUNTIME_REFERENCE_ASSEMBLY` / `WINDOWS_RUNTIME_IMPLEMENTATION_ASSEMBLY` defines, `[WindowsRuntimeImplementationOnlyMember]` attribute, `#define WINDOWS_RUNTIME_IMPLEMENTATION_ONLY_FILE` opt-out) is accurately described
    - Namespace organization matches
 
 2. **WinRT.SourceGenerator2 (`src/Authoring/WinRT.SourceGenerator2/`)**