Limits of lodash's __proto__ path guard in _.set, _.update and _.merge

Lodash deep-path utilities such as _.set, _.update and _.merge block path segments named __proto__ as part of the 4.17.x security hardening, so a path like a.__proto__.b should no longer write to Object.prototype through those APIs. The goal is to determine how far this built-in guard can be trusted when property paths or merge sources originate from untrusted input.

The constraint is that the guard is key-name based rather than a general security boundary. Paths routed through constructor.prototype have required separate fixes across different 4.17.x patch releases, so coverage depends on the exact installed version. Lodash is also in maintenance mode, and its documentation describes the blocking behavior without stating a formal security guarantee. Read-only helpers such as _.get cannot pollute prototypes, though they can still traverse inherited properties on attacker-controlled paths.

1. Which dangerous path keys does the built-in blocking actually cover in the current 4.17.x line, and where does it deliberately stop?
2. Should an application that accepts untrusted paths or merge sources add its own key validation instead of relying on lodash's guard alone?
3. Is there a version-stable, documented list of the keys lodash treats as unsafe in deep-path operations?