[browser][coreCLR] R2R: R2R composite for the startup set

# R2R composite for the startup set (follow-up to per-assembly)

Part of #130524.

Status: **draft / issue candidate** · Area: CoreCLR-on-WASM, precompilation/R2R · Related: #130522 (R2R over in-memory IL), #130523 (sharded IL), D4 · Builds on the upstream per-assembly R2R + webcil-in-wasm async-load foundation (#129634).

## Goal

Combine the per-assembly startup R2R images into a single **composite** image, so the precompiled startup and hot code ships and loads as one unit rather than many per-assembly files. This is the follow-up to the first prototype's per-assembly R2R (D4).

## Why

Per-assembly R2R is the simplest first step, but many small images mean more files, more per-image load/instantiate/fixup overhead, and cross-image calls that go through import indirection. A composite consolidates the startup set into one image with direct intra-composite calls and a single load — better code quality (fewer cross-image thunks) and more efficient startup load.

## Direction

- **One composite for the profile-selected startup + hot set**, instead of one image per assembly.
- **Direct intra-composite calls**; calls out to code not in the composite fall back through the normal import/interpreter path.
- **Browser-loadable packaging.** The composite must be emitted in the loadable-on-WASM form, not a desktop-only shape.
- **Coordinate with in-memory-IL reuse (#130522) and sharded IL (#130523).** The composite binds against the resident IL the same way the per-assembly images do, including when that IL is a facade plus shards.

## Scope

**In:** producing a single startup composite from the profile; loadable-on-WASM packaging; direct intra-composite calls with coherent fallback.

**Out:** the per-assembly R2R baseline (the prototype path); lazily-streamed shard R2R; the IL splitter/consumer.

## Success criteria

- The startup hot set ships and loads as one composite; behavior identical to the per-assembly set.
- Measurable reduction in cross-image thunking and/or load overhead versus per-assembly R2R.

## Open questions

- Whether the composite container is fully browser-loadable today or needs work (the component-file form may be desktop-shaped).
- How the composite interacts with the in-memory-IL reuse (#130522) and sharded-IL (#130523) layouts.
- Selection boundary: exactly which assemblies/methods go in the startup composite versus stay per-assembly or lazy.

> [!NOTE]
> This issue was drafted with GitHub Copilot assistance.