fix(docker): copy production node_modules into runtime stage (#2842)

* fix(docker): copy production node_modules into runtime stage

The Docker image was shipping without node_modules in the runtime
stage. The builder stage installs deps and compiles TypeScript
handlers to self-contained ESM bundles (which inline their imports),
but raw JavaScript handlers like api/enrichment/signals.js are
copied as-is and still import external packages at runtime:

    import { Ratelimit } from '@upstash/ratelimit';
    import { Redis } from '@upstash/redis';

With no node_modules present in /app, the Node sidecar dispatches
the route, fails to resolve the import with ERR_MODULE_NOT_FOUND,
and local-api-server returns 502 "missing dependency". Any caller
of GET /api/enrichment/signals in a Dockerized deployment hits this.

Fix:

1. Builder: `npm prune --omit=dev` after the build completes so the
   copied node_modules stays small (drops vite, tsc, test deps, etc.).
2. Runtime: `COPY --from=builder /app/node_modules ./node_modules`
   so raw .js handlers can resolve their imports.

Reproduction before the fix:

    docker build -t wm .
    docker run --rm -p 8080:8080 wm
    curl -i http://localhost:8080/api/enrichment/signals?company=Stripe
    # → HTTP/1.1 502 Bad Gateway
    # → {"error":"Local handler error","reason":"missing dependency", ...}

After the fix the same request returns 200 with the signal payload
(or a structured error from the handler itself, not a module-load
failure at the dispatcher layer).

Alternative considered: teach docker/build-handlers.mjs to also
bundle raw .js handlers with their deps inlined, the same way it
bundles .ts handlers. That's a more invasive change that would
require per-handler entrypoint detection and wouldn't help any
future raw-JS routes added to api/. The node_modules copy is the
smaller, more predictable fix.

* fix(docker): slim runtime dependencies

---------

Co-authored-by: spignataro <spignataro@users.noreply.github.com>
Co-authored-by: Elie Habib <elie.habib@gmail.com>