JS core utility edge cases: acf.get() falsy values, acf.isObject(null), acf._e() leaking String.prototype methods

Description

Three related edge cases in the core acf JS utilities (assets/src/js/_acf.js), grouped because fixes would land together:

1. acf.get() cannot return falsy stored values: it returns this.data[name] || null, so stored 0, '', or false come back as null, and acf.has() reports them missing.
2. acf.isObject( null ) === true: typeof null === 'object'.
3. acf._e( 'missing', 'sub' ) returns String.prototype.sub: when the first key is unknown, the lookup indexes into an empty string, so any second key naming a String method leaks that function instead of returning ''.

All three are long-standing characterized behavior; fixing them changes the public API surface subtly, so each needs a quick ecosystem-impact look (e.g. code relying on get() || default patterns is unaffected by 1).

Reproduction

Characterized in #450: tests/js/acf-utilities.test.js (NOTE comments at the get()/isObject() cases) and tests/js/compatibility.test.js (_e() case).

Found during the 2026-06 test campaign (see PR #450).

Start with assets/src/js/_acf.js and run tests/js/acf-utilities.test.js plus tests/js/compatibility.test.js. Review the characterized cases from #450 and the related API usage, then update the utility behavior and tests so falsy values, null object checks, and unknown _e() lookups behave as specified without breaking compatibility.