fix: load harper lazily in CacheHandler to avoid worker conflicts

[jjohnson-hdb]

The Next.js cacheHandler module is loaded by Next.js itself (via require() on the cacheHandler config path), not by Harper. With turbopack, that load happens inside a build worker thread. Importing harper at the top of CacheHandler.cts ran harper's module initialization in that worker thread, which tried to register native worker hooks process-wide — conflicting with the same registration already done by the Harper main process. The result was a stream of "Worker creator already registered" uncaught exceptions; the HTTP worker kept restarting until Harper gave up
(Thread has been restarted undefined times and will not be restarted).

Same load path also fires with webpack — Next.js's build init requires the cacheHandler path directly via Node's require(), which bypasses webpack externals and serverExternalPackages. With harper not present in the customer's node_modules, the build fails with MODULE_NOT_FOUND on node_modules/@harperfast/nextjs/node_modules/harper.

Switch to the same pattern plugin.ts uses: import harper for types only, and read databases from globalThis at call time. The module now loads cleanly in any context, and methods short-circuit (return null / no-op) if databases isn't available — which is the correct fallback when there is no Harper runtime to talk to.