seemsToBeLockedDown = () => {
    return (
      globalThis.Function.prototype.constructor !== globalThis.Function &&
      // @ts-ignore harden is absent on globalThis type def.
      typeof globalThis.harden === 'function' &&
      // @ts-ignore lockdown is absent on globalThis type def.
      typeof globalThis.lockdown === 'function' &&
      globalThis.Date.prototype.constructor !== globalThis.Date &&
      typeof globalThis.Date.now === 'function' &&
      // @ts-ignore does not recognize that Date constructor is a special
      // Function.
      // eslint-disable-next-line @endo/no-polymorphic-call
      is(globalThis.Date.prototype.constructor.now(), NaN)
    );
  }
Because of packagers and bundlers, etc, multiple invocations of lockdown
might happen in separate instantiations of the source of this module.
In that case, each one sees its own `firstOptions` variable, so the test
above will not detect that lockdown has already happened. We
unreliably test some telltale signs that lockdown has run, to avoid
trying to lock down a locked down environment. Although the test is
unreliable, this is consistent with the SES threat model. SES provides
security only if it runs first in a given realm, or if everything that
runs before it is SES-aware and cooperative. Neither SES nor anything
can protect itself from corrupting code that runs first. For these
purposes, code that turns a realm into something that passes these
tests without actually locking down counts as corrupting code.

The specifics of what this tests for may change over time, but it
should be consistent with any setting of the lockdown options.