Fix concurrent creation of duplicate Java peers

[simonrozsival]

Fixes a startup race where two threads create two managed wrappers for the same Java instance and each keeps a different one.

Application.Context can permanently cache a non-canonical peer, which is why Android.RuntimeTests.JnienvArrayMarshaling.GetObjectArray flakes in the CoreCLR + trimmable typemap configuration: Assert.AreSame (context, values [0]) compares the cached wrapper against the registered one.

The race

Android runs instrumentation onCreate() before application onCreate(), so during startup:

• the main thread runs App.onCreate() → Application.n_OnCreate() → GetObject<Application>(self)
• the instrumentation thread runs OnStart() → reads Application.Context

Both miss PeekPeer() for the same Java Application, both create a peer, and both register. Two things then go wrong:

1. GetPeer() returned the peer it created rather than the one that won registration.
2. Implicitly created peers were marked JniManagedPeerStates.Replaceable only after the activation constructor had already registered them, so AddPeer() could not use Replaceable to keep the first one — the second peer, not yet marked, evicted the first.

Changes

Return the registered peer.JniRuntime.JniValueManager.GetPeer() creates as before, then re-reads the registry and returns whichever peer won registration, disposing the loser. Registration was already the arbiter of peer identity; the only missing piece was handing that winner back to every caller.

Creation is deliberately not serialized. CreatePeer() runs activation constructors and Java class loading, so a lock held across it can invert against a Java monitor owned by another thread that is itself waiting to create a peer. It would also serialize every peer creation process-wide, in shared code used by all runtime configurations, while GetValue() and JavaAs() reach CreatePeer() without it.

Mark implicitly created peers before activation. Generated JavaPeerProxy.CreateInstance() overrides now allocate the peer with RuntimeHelpers.GetUninitializedObject(), mark it Replaceable, and then invoke the activation constructor, instead of using newobj. TrimmableTypeMap's reflection fallback for closed generic targets does the same.

This mirrors TypeManager.CreateProxy() in the non-trimmable typemap implementation, which already establishes the invariant this way.

Both halves are required: pre-marking makes registration a stable "first implicit peer wins" arbiter, and canonicalization makes every caller receive that winner.

Suppress a now-expected warning. With pre-marking, two concurrently created implicit peers are both Replaceable when they meet in AddPeer(). That is the normal outcome, so it no longer logs Warning: Not registering PeerReference=....

Rejected alternative

An earlier revision passed JniHandleOwnership.DoNotRegister through CreateInstance() so registration could happen explicitly, after construction. That flag never reaches ConstructPeerCore() for two families of peers — Java.Lang.Throwable.SetHandle() hardcodes JniObjectReferenceOptions.Copy, and so do both generated Java.Interop-style activation paths — so the invariant silently did not hold for them. It also left peers unregistered while their constructors ran, where JavaPeerProxy.ShouldSkipActivation() and GetActivationPeer() would no longer find them.

Validation

• Java.Interop-Tests: 680 passed, 6 skipped. GetPeer_ReturnsRegisteredPeerConcurrently uses a barrier to force both callers past the initial PeekPeer() miss, then asserts both created a peer and both received the registered winner.
• Microsoft.Android.Sdk.TrimmableTypeMap.Tests: 801 passed, including two new tests asserting the generated CreateInstance allocates uninitialized, calls MarkCreatedPeerReplaceable(), and calls the activation constructor rather than newobj-ing it — for both XA-style and Java.Interop-style leaf constructors.
• Mono.Android.csproj builds clean.

Still to do: an on-device run of JnienvArrayMarshaling.GetObjectArray in Release/CoreCLRTrimmable.

Closes#10973