* fix: compile bundled hook handlers in tsdown build
The migration from tsc to tsdown in 2026.2.2 dropped bundled hook handlers
from the build output. The copy-hook-metadata.ts script only copies HOOK.md
metadata files, not the handler.ts source files. Without corresponding tsdown
entry points, the handlers were never compiled to JS, causing
`openclaw hooks list` to show 0 hooks on npm installs.
This adds each bundled hook handler and the llm-slug-generator (dynamically
imported by session-memory) as tsdown entry points:
- src/hooks/bundled/session-memory/handler.ts
- src/hooks/bundled/command-logger/handler.ts
- src/hooks/bundled/boot-md/handler.ts
- src/hooks/bundled/soul-evil/handler.ts
- src/hooks/llm-slug-generator.ts
Regression introduced in 2026.2.2; versions 2026.1.29–2026.2.1 worked
correctly under the previous tsc build.
* refactor: use glob for bundled hook entries, fix dist output paths
- Replace hardcoded entry list with glob pattern in tsdown.config.ts
so new hooks are auto-discovered (matching scripts/copy-hook-metadata.ts)
- Remove inconsistent comment block from tsdown.config.ts
- Fix copy-hook-metadata.ts to copy HOOK.md to dist/bundled/ (matching
the runtime resolution in bundled-dir.ts which resolves path.join(moduleDir, 'bundled')
relative to the chunk in dist/)
- Update stale path comment in session-memory handler
The previous migration to tsdown was reverted because it caused a ~20x slowdown when running OpenClaw from the repo. @hyf0 investigated and found that simply renaming the `dist` folder also caused the same slowdown. It turns out the Plugin script loader has a bunch of voodoo vibe logic to determine if it should load files from source and compile them, or if it should load them from dist. When building with tsdown, the filesystem layout is different (bundled), and so some files weren't in the right location, and the Plugin script loader decided to compile source files from scratch using Jiti.
The new implementation uses tsdown to embed `NODE_ENV: 'production'`, which we now use to determine if we are running OpenClaw from a "production environmen" (ie. from dist). This removes the slop in favor of a deterministic toggle, and doesn't rely on directory names or similar.
There is some code reaching into `dist` to load specific modules, primarily in the voice-call extension, which I simplified into loading an "officially" exported `extensionAPI.js` file. With tsdown, entry points need to be explicitly configured, so we should be able to avoid sloppy code reaching into internals from now on. This might break some existing users, but if it does, it's because they were using "private" APIs.
