`ns.foo = value` previously generated `<importVar>.a.foo = value`
whose `.a` getter eagerly required the deferred module, violating
the TC39 import-defer `[[Set]]` algorithm. Tap `assignMemberChain`
for `harmonySpecifierTag` to walk only the bare `ns` identifier so
it resolves to the deferred-namespace proxy (whose `set` trap
returns false without triggering evaluation), and leave the
`.foo = value` assignment as plain code.

Cache the deferred-namespace proxy per-`moduleId` in a new global
`__webpack_module_deferred_namespace_cache__`, and stop the
`__webpack_require__.z` cached-module fast path from short-circuiting
to the underlying exports for namespace-mode imports. This keeps
the deferred and eager namespaces as distinct objects (per spec)
and shares one Deferred Module Namespace Exotic Object across all
defer-import call sites for the same module.

Address Copilot's review on #20913: key the deferred-namespace cache
by `(moduleId, shapeMode)` instead of just `moduleId`. `shapeMode` is
`mode & ~16` so the irrelevant `createFakeNamespaceObject` async-wrap
bit is normalized out — static defer (mode 8) and dynamic
`await import.defer` (mode 8 | 16) for the same module still share
the same Deferred Module Namespace object — but distinct
exports-type shapes (e.g. one importer treats a CJS module as
"default-with-named", another as "namespace") get distinct cache
entries instead of returning the wrong shape.

Add config tests:
- `identity-across-call-sites`: same module imported defer multiple
  times, plus static defer + dynamic `import.defer`, must yield the
  same object; defer must stay distinct from eager.
- `set-does-not-trigger-evaluation`: assigning to a deferred
  namespace property (exported or not) throws TypeError in strict
  mode without triggering module evaluation; subsequent property
  read still evaluates.

Address Copilot follow-up on #20913: the cache key was masking off
bit 16 (`shapeMode = mode & ~16`) but the original `mode` was still
being passed to `createFakeNamespaceObject`. Whichever call site ran
first would decide whether the cached entry had `createFakeNamespace
Object`'s "return value when it's Promise-like" short-circuit
applied, so static `import defer` and dynamic `await import.defer`
could observe different wrapping semantics for the same cache slot.

Strip bit 16 once at the top of the runtime helper so the cache
key, the gate that decides between the cached-module fast path and
the lazy Proxy, and the value passed to `createFakeNamespaceObject`
all use the same `mode`. The bit is irrelevant in this runtime
helper anyway — the value passed into `createFakeNamespaceObject`
here is always the resolved module exports (after unwrapping the
async-module export symbol when present), never a Promise.

Address Copilot follow-up on #20913: now that the deferred-namespace
Proxy is cached globally, mutations to its handler at init time
persist across all defer-import call sites for the lifetime of the
bundle. The previous post-init optimization deleted *all* handler
traps, including `set`, `deleteProperty`, and `defineProperty`,
which caused `ns.notExported = "x"` to silently mutate the proxy
target after the first read had triggered evaluation — `[[Set]]` on
a Module Namespace Exotic Object must always return false per the
TC39 import-defer spec.

Keep the three mutation traps and only drop the read-side traps
(`get`, `has`, `ownKeys`, `getOwnPropertyDescriptor`); with the
resolved namespace's own keys mirrored onto `ns_target`, the
default `Reflect` behavior already returns the right values via
the live-binding getters.

Add a `set-does-not-trigger-evaluation` regression test asserting
that strict-mode assignment to both an exported and a non-exported
key still throws TypeError after the deferred module has been
evaluated, and that no spurious property is created on the target.

`set-does-not-trigger-evaluation` reads `globalThis.evaluations`
which is unavailable on Node.js 10, and `identity-across-call-sites`
uses `await import.defer(...)` whose nested async/await pattern
hits the Node.js 10 bug `supportsAsync` already gates against.