[browser][CoreCLR][R2R] Filesystem timestamp tests load kernel32.dll through guarded IsInAppContainer

### Description

Trimmed browser CoreCLR R2R library tests fail when filesystem timestamp tests initialize `BaseGetSetTimes`. Its `PlatformDetection.IsInAppContainer` call throws `DllNotFoundException` for `kernel32.dll`, despite the helper having an early `!IsWindows` return before the Windows P/Invoke.

This is classified as **R2R-only execution behavior rather than a missing trimming descriptor**: a clean aggressively trimmed non-R2R run of an affected group passes. Eager P/Invoke fixup resolution is a possibility, but the precise cause has not been established.

### Reproduction Steps

Build browser CoreCLR, libraries, host, packs, and host crossgen2. Reproduced on `798449390515fa02f4b20160bedc5e34f8fbdfb9` plus publishing prerequisite #133378 (`245cb70d593f2c8f3a4e23bcc422e7da5926e15b`), with the existing mobile filesystem and StreamConformance trimming descriptors also enabled for browser aggressive trimming.

```sh
XHARNESS_COMMAND=test-browser ./dotnet.sh build /t:Test \
src/libraries/System.Runtime/tests/System.IO.FileSystem.Tests/System.IO.FileSystem.Tests.csproj \
/p:TargetOS=browser /p:TargetArchitecture=wasm /p:RuntimeFlavor=CoreCLR /p:Configuration=Release \
/p:PublishReadyToRun=true /p:EnableAggressiveTrimming=true \
/p:Scenario=WasmTestOnChrome /p:InstallChromeForTests=true /p:XunitShowProgress=true
```

For the comparison, use clean project-specific browser-wasm obj/bin outputs, set `PublishReadyToRun=false`, retain `EnableAggressiveTrimming=true`, and add:

```text
/p:WasmTestAppArgs="-class System.IO.Tests.File_GetSetTimes_SafeFileHandle"
```

### Expected behavior

Browser execution should return false from `PlatformDetection.IsInAppContainer` without loading a Windows library, and the timestamp tests should run.

### Actual behavior

The R2R suite completed with **6,454 total: 6,184 passed, 26 failed, 244 skipped**. The failures share this type-initializer error:

```text
System.TypeInitializationException: The type initializer for 'System.IO.Tests.BaseGetSetTimes`1' threw an exception.
---- System.DllNotFoundException: Unable to load shared library 'kernel32.dll' or one of its dependencies.
dynamic linking not enabled
at System.PlatformDetection.get_IsInAppContainer()
at System.IO.Tests.BaseGetSetTimes`1..cctor()
```

Affected methods are inherited timestamp cases such as `SettingUpdatesProperties`, `SettingUpdatesPropertiesWhenReadOnly`, `SettingUpdatesPropertiesAfterAnother`, `TimesIncludeMillisecondPart`, and `TimesNotIncludeMillisecondPart`, across File, FileInfo, Directory, and DirectoryInfo variants.

The clean trimmed non-R2R comparison group reports **14 total: 11 passed, 0 failed, 3 skipped**.

### Regression?

Unknown. Only R2R-on versus R2R-off was compared; both retain aggressive trimming.

### Known Workarounds

Disable R2R. During library-test bring-up, quarantine the affected timestamp cases specifically for browser R2R while retaining interpreter coverage.

### Configuration

Browser-wasm CoreCLR Release, macOS arm64 build host, Chromium 153.0.8010.0, SDK 11.0.100-rc.1.26420.103.

### Other information

Found while standing up trimmed R2R library tests for #133193. #131874 describes different build-time P/Invoke/struct-mapping failures; this report concerns a runtime DLL load in a guarded platform-detection helper.

> [!NOTE]
> This issue was generated by GitHub Copilot from local build and test results.

Start with src/libraries/System.Runtime/tests/System.IO.FileSystem.Tests/System.IO.FileSystem.Tests.csproj and the System.IO.Tests.File_GetSetTimes_SafeFileHandle group. Compare the browser aggressively trimmed runs with PublishReadyToRun enabled and disabled, then trace PlatformDetection.IsInAppContainer and the BaseGetSetTimes type initializer. Done means the R2R browser run avoids loading kernel32.dll and the timestamp tests pass without disabling R2R.

Written by the indexing model from the issue text.