fix(vtex): defer registry import to first request to fit Workers startup CPU

[viktormarinho]

Summary

• Follow-up to feat(vtex): migrate to Cloudflare Workers deploy #424. The first deploy failed with Script startup exceeded CPU time limit — vtex/server/tools/registry.ts statically imports ~70 generated zod modules (~35k lines of `z.object()` calls) and synchronously flattens schemas for 708 tools, all at module init, blowing past Cloudflare's startup CPU budget.
• Switch `vtex/server/tools/index.ts` to dynamic-import `./registry.ts` inside an async tools factory; esbuild emits `__esm` lazy module wrappers so the heavy chained inits only run on first MCP request. Verified the bundle has a single call site for `init_registry2` gated inside the async factory.
• The runtime (`@decocms/runtime/tools.ts`) already supports the function-form `tools` field and resolves it lazily on first request, so no runtime change required.

Test plan

• `bun run check` clean
• `bunx wrangler deploy --dry-run` succeeds; bundle 5.8MB / 905KB gzip
• Bundle inspection: `init_registry2` called only from inside the async tools factory — no startup-time invocation
• Post-merge: confirm `Deploy VTEX MCP` workflow goes green and `vtex-mcp.decocms.com/mcp` responds to `tools/list`
• First request will be slow (all the deferred work happens then) — watch for per-request CPU limits; may need `[limits] cpu_ms` bump in wrangler.toml

🤖 Generated with Claude Code

---

Summary by cubic

Defer loading of VTEX registry tools to the first request to avoid Cloudflare Workers startup CPU limits and unblock deploys. Switch vtex/server/tools/index.ts to an async tools factory that dynamic-imports ./registry.ts.

• Bug Fixes
  • Dynamic-import ./registry.ts and instantiate registry tools on demand; custom tools remain eager.
  • Return created tools by mapping factories with env; no runtime changes needed since function-form tools is already supported.

^{Written for commit 309129b. Summary will update on new commits.}