fix(harmony): load core aspects from bit's own install when workspace dist is missing

[davidfirst]

Problem

When a workspace loads envs from root node_modules (resolveEnvsFromRoots: true), an env's constructor can eagerly require('@teambit/builder') (and @teambit/ui) at module-load time. In a workspace where the core aspects are source components — most notably the Bit repo itself — that require resolves to the workspace copy, whose dist/main doesn't exist yet during bit install (before bit compile). Result: Cannot find module '.../@teambit/builder/dist/index.js' and the install crashes.

This isn't specific to core-aspect-env: node, node-babel-mocha, node-typescript-mocha, and base-react-env all eagerly touch @teambit/builder the same way.

Fix

Add a last-resort fallback in hook-require.ts: when a @teambit/* core-aspect package fails to load, re-resolve it from Bit's own installed context (which always ships compiled dist) and load that. It only runs on the existing crash path, so the happy path — every normal user workspace where these are registry packages with dist present — is untouched.

Why

Unblocks setting resolveEnvsFromRoots: true in the Bit repo, which lets envs load from node_modules instead of stacking per-version scope-aspects capsules in the global cache. The flag flip is a follow-up, after this ships in a nightly (the crash occurs inside the released bbit during setup_harmony, so it must land here first).

[davidfirst]

Superseded by #10481, which fixes this in the install/resolution layer (link Bit's own compiled core aspects into bit-roots, mirroring what scope-aspects capsules already do) instead of adding a fallback to the shared require hook. The require-hook change shipped to every Bit user for a bit-dev-only bootstrap concern; the resolution-layer fix is a provable no-op for any workspace that doesn't author Bit's core aspects.