feat(mongosh): implement multi-stage build and optimize image size

[jahirvidrio]

I've implemented a multi-stage build to significantly reduce the final image size.

Changes:

• Introduce multi-stage build to reduce final image footprint.
• Implement node-prune and manual cleanup of .d.ts, .ts, and .map files.
• Fetch mongosh tarball directly from NPM registry for a leaner build.

[ozbillwang]

Not big difference

# local build
mongosh latest 1ba69f95656b   About a minute ago   520MB

# existing alpine/mongosh
alpine/mongosh  latest 2d7a9cb13f43   2 years ago     559MB

[jahirvidrio]

You’re right, the size difference isn't that big. I think I misleadingly framed this PR by focusing on 'optimization' in the title, but the real goal is to finally unblock the mongosh update, which has been stuck for two years.

The current approach in #31 is hitting a wall because the new mongosh needs glibc. Trying to force glibc into Alpine (using frolvlad or sgerrand) just adds technical debt and security risks, especially regarding base image trust, as you mentioned.

I am considering building our own Alpine + glibc base image in the future.

Main reason is, the image (https://hub.docker.com/r/frolvlad/alpine-glibc/) doesn't mention anything about where it is built from (it's own Github or gitlab source code and automation cicd pipeline to check). It will be high risk to use this type of image as base images

About the Node.js CVEs, I actually think using node:lts-alpine is safer. The standalone mongosh binary is a static-like bundle that includes a fixed Node.js runtime. If that Node version has a vulnerability, we’re stuck waiting for a new mongosh release. By using the official Node image, we can patch vulnerabilities immediately just by updating the base image. Plus, we get native musl support, which fixes the DNS and symbol errors (__res_nsearch) that we've been seeing in #31.

This PR is a clean, working way to get mongosh 2.x out there now, without the headache of maintaining a custom Alpine+glibc layer.