[BUGFIX] Trigger glimmer opcode bootstrap from the VM, not the barrel

The smoke tests on #21350 fail with "Cannot read properties of null
(reading 'syscall')" in `AppendOpcodes.evaluate`. Cause: the lint
autofix replaced barrel imports of `@glimmer/runtime` with deep paths
(`@glimmer/runtime/lib/...`), so nothing pulled in the package index.
The index's `import './lib/bootstrap';` was the only thing loading the
opcode handler files (each `lib/compiled/opcodes/*.ts` registers via
top-level `APPEND_OPCODES.add(...)`), so 28 of 90 handlers stayed
unregistered.

Fix: own the bootstrap from the file that actually consumes registered
handlers — `lib/vm/low-level.ts`, where `evaluateSyscall` calls
`APPEND_OPCODES.evaluate(...)`. Any deep-import path that uses the VM
(directly or transitively) now triggers bootstrap; consumers that
don't need the VM don't pay for opcode handlers in their bundle.

Verified by counting top-level `APPEND_OPCODES.add(...)` calls in
`dist/dev`:

  origin/main:                   90 in a chunk loaded by everyone
  nvp/remove-barrel-imports:     62 loaded + 28 trapped in the unused
                                 `@glimmer/runtime/index.js`
  this commit:                   90 reachable from
                                 `@ember/-internals/glimmer/index.js`

Note for reviewers: the validator duplicate-package guard in
`@glimmer/validator/index.ts` and the `class EmberObject extends
CoreObject.extend(Observable)` extension in `@ember/object/index.ts`
are also barrel-only side effects. EmberObject's case is handled
naturally — `import EmberObject from '@ember/object'` is a default
import, which the lint rule's `kept` mechanism preserves on the
barrel. The validator guard becomes dormant under deep imports; if
that's a concern, move the registration check into a shared leaf
module (e.g. `lib/meta.ts`) in a follow-up.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Author: NullVoxPopuli

packages/@glimmer/runtime/index.ts

@@ -1,8 +1,3 @@
-/**
- * @deprecated use RichIteratorResult<Tick, Return> or TemplateIterator instead
- */
-import './lib/bootstrap';
-
 import type { RichIteratorResult } from '@glimmer/interfaces';
 
 export { clear, ConcreteBounds, CursorImpl } from './lib/bounds';

packages/@glimmer/runtime/lib/vm/low-level.ts

@@ -16,6 +16,11 @@ import { $fp, $pc, $ra, $sp } from '@glimmer/vm/lib/registers';
 import type { DebugState } from '../opcodes';
 import type { VM } from './append';
 
+// Loading the VM is what creates the demand for opcode handlers — its
+// `evaluateSyscall` calls `APPEND_OPCODES.evaluate(...)`. Pull bootstrap in
+// here (rather than at the package barrel) so consumers using deep imports
+// still get every opcode handler registered before the VM runs.
+import '../bootstrap';
 import { APPEND_OPCODES } from '../opcodes';
 
 export type LowLevelRegisters = [$pc: number, $ra: number, $sp: number, $fp: number];