fix: prevent prototype pollution in mergeDeep

[gistrec]

Summary

PR #712 added a __proto__ / constructor guard to MergeDeep.compareDeep (lib/mergeDeep.js:95-97). The sibling function MergeDeep.mergeDeep — which performs the same kind of recursive object merging and is the one that actually applies the parsed YAML / JSON config into the running target — did not receive the matching guard. This PR closes that gap.

Where the gap was

MergeDeep.mergeDeep had two places where a __proto__ key on a parsed config object could redirect the merged target's prototype chain:

1. mergeEmptyTarget (lib/mergeDeep.js:312 pre-PR): used target = Object.assign({}, source). When source is the result of JSON.parse or js-yaml's loader and contains __proto__ as an own enumerable property, Object.assign invokes the __proto__ setter on the new target and rewrites its prototype. Replaced with a manual copy that skips both reserved keys.

2. mergeDeep main loop (lib/mergeDeep.js:327 pre-PR): iterated every key on source, including __proto__ and constructor, before recursing into this.mergeDeep(target[key], source[key]). Added the same guard that already exists in compareDeep.

Test

Added mergeDeep does not allow prototype pollution in test/unit/lib/mergeDeep.test.js. It feeds a JSON-parsed __proto__ / constructor payload through mergeDeep, then asserts:

• Object.prototype is not modified;
• a fresh {} does not carry the payload;
• the returned merged object does not carry the payload.

I confirmed the regression test fails on main-enterprise with only the second fix applied (the first hop pollutes via mergeEmptyTarget before the loop guard runs), and passes once both fixes are in place.

Verification

npm ci
npx jest test/unit/lib/mergeDeep.test.js      # 26 / 26 passed (was 25)
npx jest --roots=lib --roots=test/unit         # 117 / 117 passed, 14 skipped

Both fixes preserve existing behavior for all non-__proto__ / non-constructor keys, so the rest of the suite is unchanged.

Notes

I treated this as a defense-in-depth follow-up to PR #712 rather than as a separately reportable issue: configs are sourced from the admin repo, and the realistic write paths into them are already privileged. The patch matches the pattern the project already chose for compareDeep, so the two recursive merge functions behave consistently.