Contain CLR type and member resolution

[sebastienros]

Summary

• close CLR namespace discovery over an explicit assembly allow-list and effectively public types
• apply member policy to top-level, nested, static, constructor, generic, and wrapper resolution paths
• require AllowGetType for widening helpers while preserving wrapper-specific explicit TypeReference provenance
• keep normalized nested-type lookup process-cached through a collectible-safe ConditionalWeakTable
• align denied member/generic errors with the sanitized-by-default disclosure policy and preserve fatal exception propagation

Stack

Base: #3051 (sebros/stack-host-error-redaction)

#3051 -> #3046 -> #3045 -> #3037 -> #3036 -> #3035 -> #3030

Integration and review

The two previously reviewed containment commits were transplanted unchanged onto live base aa5a91b8ea2c31c8c357df4516534920061ae8c9; they applied without manual conflicts. Integration then sanitized unresolved-member and generic-binding failures, prevented raw generic exceptions under default policy, and preserved fatal resource/control exceptions.

Fresh specialist review found two Assembly.GetType visibility bypasses: CLR + names could reach non-public nested types, and internal top-level types remained resolvable. Both were fixed with an effective-public check across the complete declaring-type chain. The final follow-up security review was clean.

Validation

• Release multi-target Jint/Jint.csproj build
• Jint.Tests: 5,774 passed, 4 skipped (default and host-contract verification)
• Jint.Tests.PublicInterface: 1,707 passed / 9 skipped default; 1,711 passed / 5 skipped with host-contract verification
• focused CLR containment, explicit TypeReference, nested-type, cache, GC, reflection, debugger, module, result, and security coverage included in the full suites
• git diff --check

NuGet validation used only https://packagefeedproxy.microsoft.io/nuget/v3/index.json; the proxy-compatible analyzer downgrade was local-only and the manifest is restored exactly.

Performance

Default BenchmarkDotNet job, fresh-engine probe:

Scenario	Mean	Ratio	Allocated
Compatibility fresh engine	1.181 us	1.00	11,499 B
Restrictive fresh engine	1.170 us	0.99	11,499 B
Restrictive + cached nested resolution	2.695 us	2.28	17,766 B
Same workload with former per-engine scan simulated	12.455 us	10.55	58,705 B

Restrictive construction is allocation-neutral and within noise of compatibility mode; the process cache avoids about 9.76 us and 40.9 KB per fresh-engine nested lookup versus the former scan shape.

[lahma]

Reviewed as the incremental diff against sebros/stack-host-error-redaction. This closes a real escape: the old NamespaceReference.GetPath searched the calling/executing assemblies and then fell back to System.Type.GetType(path) — which accepts assembly-qualified names, i.e. script-triggered assembly loading. Replacing that with a closed allow-list plus an effective-public declaring-chain check, and filtering the static Type.GetType family out of member resolution unconditionally, is exactly right. The per-assembly ConditionalWeakTable type-name index is collectible-assembly-safe and engine-independent, and moving the static-member and constructor caches onto TypeResolver keyed by resolution profile finally fixes the weak-keyed process-wide TypeReference cache that AGENTS.md has been flagging as a hazard. The explicit-capability story is coherent throughout: a host-exported TypeReference stays a capability (including the CWT round-trip through typeToObject/objectToType), while anything discovered through a namespace passes the policy. Benchmark numbers show restrictive construction allocation-neutral and the nested-lookup cache paying for itself. Approving.

Notes:

1. Breaking changes to catalog in the release notes (all deliberate): AllowClr(...) no longer implicitly searches the calling/executing assembly or Type.GetType — an embedder who relied on that must now pass their assemblies explicitly (parameterless AllowClr() keeps core-lib types working); clrHelper.unwrap now requires AllowGetType; static Type.GetType(string) is filtered even when AllowGetType is true (a host that wants it can export a delegate).
2. Subtlety worth a doc line: ClrTypeResolutionPolicy.Allows checks AllowedAssemblies.Contains(type.Assembly) on the resolved type, and Assembly.GetType follows type forwarders. A host that allow-lists a facade assembly (e.g. System.Runtime) will have its types resolve into core-lib and then be denied because the forwarded type's Assembly is not the facade. "Allow-list the assembly that defines the type (typeof(X).Assembly)" is the guidance to write down.
3. GetConstructors caches per Type without the resolution profile in the key — currently fine because constructor filtering only consults resolver-level state (_memberFilter, cleared on change), not the engine profile. If Filter ever grows a profile-dependent branch that applies to ConstructorInfo, this key needs the profile too; a one-line comment on the cache would keep that from being missed.

Stack merge still gated on the #3035 fix below.