fix: prevent prototype confusion via __proto__ key in Object.fromEntries polyfill

[prasanna8585]

Object.fromEntries's polyfill assigns each key/value pair with obj[key] = val. When the source iterable yields a pair whose key is the string "__proto__", that plain assignment invokes Object.prototype's __proto__ accessor setter instead of creating an own property — reassigning the returned object's own [[Prototype]] to the caller-supplied value, rather than storing it as an own "__proto__" property as ECMA-262 24.1.1.2's CreateDataPropertyOrThrow requires.

Any code that builds an object from an untrusted iterable of key/value pairs (URLSearchParams, parsed JSON pairs, form data, etc.) via this polyfill is affected: an attacker-supplied ["__proto__", someObject] pair silently reassigns the resulting object's prototype, so inherited properties on someObject appear to be legitimate values on the returned object to any code inspecting it afterward.

This is the same defect class already fixed for Object.getOwnPropertyDescriptors's polyfill in this codebase (f32e2796f, "Fix Object.getOwnPropertyDescriptors polyfill to prevent prototype injection"), which switched to Object.defineProperty for the identical reason. This applies the same fix here.

Verified with a standalone Node script exercising the extracted polyfill logic — before the fix, an attacker-controlled __proto__ key reassigns the object's prototype and inherited properties (e.g. isAdmin) become visible on the result; after the fix, the prototype stays Object.prototype, __proto__ is stored as a normal own property (matching spec), and ordinary key/value, duplicate-key, and symbol-key behavior are all unchanged.

[concavelenz]

We already have a change internal to Google under review that should be pushed out in the next few day.