Add Copilot skill: reproduce CI runs locally for dotnet/android lanes

## Problem

When a CI lane fails (e.g. CoreCLRTrimmable, NativeAOT, or a specific device test suite), an agent/contributor trying to reproduce it locally has to reverse-engineer:

- Which `dotnet-local.sh` target to invoke
- Which MSBuild properties to pass (`_AndroidTypeMapImplementation`, `UseMonoRuntime`, `RuntimeIdentifier`, etc.)
- Which configuration to use (Debug vs Release)
- How to run the *device* test (with emulator attached) vs the *host* test
- Where to find the results XML

This burned a significant amount of time during PR #11091 and forced CI-driven iteration (hours per cycle) instead of local iteration (minutes per cycle).

## Proposal

Add a `.github/skills/reproduce-ci-run/SKILL.md` that maps a CI lane name to the exact local commands. Sketch:

```
Given: CoreCLRTrimmable lane failure
Produce:
make prepare && make all CONFIGURATION=Release
./dotnet-local.sh build tests/Mono.Android-Tests/Mono.Android-Tests/Mono.Android.NET-Tests.csproj \
-t:RunTestApp -c Release \
-p:_AndroidTypeMapImplementation=trimmable \
-p:UseMonoRuntime=false
Parse TestResult-Mono.Android.NET_Tests-ReleaseCoreCLRTrimmable.xml
```

Coverage should include at minimum:
- Mono vs CoreCLR vs NativeAOT
- legacy vs trimmable typemap
- Debug vs Release
- Device tests (emulator/phone attached) vs host tests
- Build-only smoke vs full test matrix

## Acceptance criteria

- [ ] Skill exists with frontmatter (name, description) and is triggered by phrases like "reproduce CI locally", "run CoreCLRTrimmable tests locally".
- [ ] Covers the lane/configuration combinations listed above.
- [ ] Documents where results land and how to parse them.
- [ ] Validated by reproducing at least one recent CI failure end-to-end.

## Discovered during

PR #11091 — adding the CoreCLRTrimmable CI lane. See also companion issue about investigation/debugging practices (already added to `.github/copilot-instructions.md`).