extract and export buildProject for flight-instructor on-demand gener…

[qiaozha]

…ation

[JialinHuang803]

I may have some concerns here - if a new helper is added, we'd need to update both places, which is easy to forget and hard to contain.

[JialinHuang803]

I am thinking about aggregating the code from line 729 (provideContext) to this line as a new shared method called something like initializeModularPipeline() which returns the binder, and both $onEmit and buildProject can call it. In this way, the structure would be like:

   ├── $onEmit(context)                          [ENTRY POINT — TypeSpec compiler hook]
   │   │  Orchestrates the full emitter pipeline: FS setup, RLC or Modular
   │   │  generation, metadata, tests, and writing files to disk.
   │   │
   │   ├── ...
   │   │
   │   ├── generateModularSources()             [MODULAR — emit source files]
   │   │     Calls initializeModularPipeline() → generateModularSourcesInProject()
   │   │     → binder.resolveAllReferences() → writes files to disk.
   │   │
   │   └── ...
   │
   ├── generateModularSourcesInProject(...)     [SHARED — modular source generation]
   │     Pure generation logic: emit types, build clients, operations,
   │     index files. No FS, no context wiring, no binder resolution.
   │     Used by both $onEmit and buildProject.
   │
   ├── initializeModularPipeline(...)           [SHARED — pipeline bootstrap]  ✨ NEW
   │     Wires up provideContext, loads static helpers, resolves
   │     dependencies, creates binder. SINGLE SOURCE OF TRUTH for
   │     helpers/deps registration.
   │
   ├── buildProject(program, options)           [ENTRY POINT — programmatic API]
   │     In-memory modular generation for flight-instructor.
   │     Creates fake EmitContext → initializeModularPipeline()
   │     → generateModularSourcesInProject() → binder.resolveAllReferences()
   │     → returns ts-morph Project (no disk writes).

Not sure if it would be better.