How would you write a Proxy 'set' trap that validates a value before allowing an assignment, and what happens if you return false?

Question presented to candidate: "You want an object where setting user.age to something invalid — a negative number, say — is genuinely rejected rather than silently stored. How would a Proxy's set trap do that, and what actually happens to the write if the trap says no?"

What a strong answer should cover:

• 📌 Interview term: a set trap's real return value IS the signal — returning true tells the engine the write genuinely succeeded; returning false tells it the write was genuinely rejected — the trap itself decides whether to actually store the value at all.
• 📌 Verified, not assumed: a real validating set trap genuinely rejected an invalid value (a negative age) — the real underlying value was confirmed to genuinely remain unchanged — while a valid value genuinely updated it.
• 📌 Interview term: the real, mode-dependent failure signal — in sloppy mode, a real rejected write (trap returns false) genuinely fails silently, with no error and no visible signal the assignment did not happen. In real strict mode, the identical rejected write genuinely throws a real TypeError ("trap returned falsish for property") — directly answering the prompt's "what happens if you return false" with a real, mode-dependent answer, not one universal behavior.
• A precise answer names this as the identical real proxy-invariant-enforcement pattern verified elsewhere in this bank for a getter-only property write — JavaScript consistently treats a "this operation was refused" signal the same way across different mechanisms.
• The precise, honest scope: a set trap can validate against ANY logic — a type check, a range check, a regex, even checking against other properties on the same object — verified directly with a real, working range/type validator.

Clarifying questions expected:

• "Should an invalid write genuinely throw immediately (surfacing the bug loudly), or fail silently and let the caller separately check whether it actually took effect?" — directly determined by whether the actual calling code runs in strict mode, verified above as the real deciding factor.
• "Does the validation logic ever need to reference OTHER properties on the same object (a cross-field validation), not just the single value being written?" — a real, genuine extension the set trap's own signature (which receives the full target object) directly supports.

Code / implementation expected: Yes — a real set trap genuinely rejecting an invalid value and genuinely accepting a valid one, plus a real, direct side-by-side of the sloppy-mode-silent versus strict-mode-throwing failure signal, is the concrete, convincing proof of exactly what returning false actually does.