Use pre-generated commands/events tree in production builds with incremental tree generation in development

[twlite]

Background

Currently, CommandKit generates the commands and events tree at runtime on every startup, regardless of the environment. This means production deployments pay the full cost of filesystem traversal, module resolution, and tree construction on each cold start, even though the source tree is static in production.

Proposed Behavior

Production

The commandkit build step should emit a serialized representation of the resolved commands/events tree as part of the compilation output. At runtime, CommandKit should deserialize and hydrate this pre-generated tree directly, bypassing all filesystem traversal and dynamic resolution. This makes startup time effectively a constant, independent of the number of commands or event handlers.

Development

Development mode (commandkit dev) should retain just-in-time tree generation to support hot-reloading. However, instead of reconciling the entire tree on every file change, the router should support incremental tree updates, where only the subtree affected by the changed module is invalidated and rebuilt. The rest of the tree should remain intact across reloads.

Motivation

• Cold start performance in production is directly proportional to the size of the command/event tree today. Pre-generation eliminates this scaling issue entirely.
• Full tree reconciliation on each HMR cycle in development introduces unnecessary overhead and can cause observable reload lag on larger bots.

Acceptance Criteria

• The compiler/build pipeline emits a serialized tree artifact alongside the production output.
• The runtime detects the presence of the pre-generated artifact and uses it instead of performing dynamic tree resolution.
• Development mode continues to resolve the tree at runtime, with no regression in hot-reload behavior.
• The development router invalidates and regenerates only the affected subtree when a file changes, rather than the full tree.
• The serialized tree format is versioned or validated at startup to prevent stale artifact mismatches.

Additional Considerations

• The serialized artifact should be treated as a build output (placed inside dist for prod or .commandkit for dev) and excluded from version control (.gitignore).
• If the artifact is absent at runtime in production (e.g., running node directly without building), CommandKit should either fall back to dynamic resolution.
• The incremental dev strategy should account for newly added or deleted files, not just modifications to existing ones.