Expose `collectProcessMetrics` as a CLI/env config option

[DrFaust92]

Summary

@mongodb-js/mcp-metrics already supports Node.js/process metrics via
PrometheusMetricsOptions.collectProcessMetrics, but there is no way to enable it
when running the published server (CLI or Docker image). Only library consumers who
construct their own PrometheusMetrics can turn it on.

Result: an HTTP-transport deployment scraping /metrics gets the three MCP metrics but
no heap, GC, event-loop-lag, or file-descriptor metrics for what is a long-running
Node process.

Detail

Refs against main (commit b5c6f19):

• packages/metrics/src/types.ts:16 declares the option:

  /** Whether to collect Node.js and process metrics. */
  collectProcessMetrics?: boolean;

• packages/metrics/src/prometheusMetrics.ts:8 defaults it to false and gates
  collectDefaultMetrics() on it.
• src/transports/base.ts:238 — the default construction path never passes it:

  this.metrics = metrics ?? new PrometheusMetrics({ definitions: createDefaultMetrics() as TMetrics });

• src/common/config/userConfig.ts has no corresponding key, so there is no flag or
  MDB_MCP_* env var to set it.

So --monitoringServerFeatures=metrics yields exactly mcp_tool_execution_duration_seconds,
mcp_session_created, and mcp_session_closed.

Why it matters

When the server is deployed as a long-lived HTTP service (Kubernetes, scraped by
Prometheus), process-level metrics are the difference between "a tool call was slow"
and "the process is heap-constrained / GC-thrashing / the event loop is blocked."
Those are the first metrics you want when diagnosing latency in a Node service, and
prom-client already collects them — the wiring is the only thing missing.

Proposed change

Add a config key that threads through to the existing option, e.g.:

MDB_MCP_MONITORING_SERVER_COLLECT_PROCESS_METRICS / --monitoringServerCollectProcessMetrics

defaulting to false to preserve current behaviour and keep stdio invocations
cardinality-free. Alternatively, treat it as a third monitoringServerFeatures value
(process-metrics) alongside health-check and metrics, which avoids a new
top-level flag:

--monitoringServerFeatures=health-check,metrics,process-metrics

Either shape works for us; the feature-list variant seems more consistent with
src/common/schemas.ts:4.

Environment

• Server version: v1.14.0 (Docker image), HTTP transport
• Monitoring server enabled with --monitoringServerFeatures=health-check,metrics

Happy to open a PR if you have a preference on which of the two shapes you'd accept.

[gagik]

Thank you for raising this, I can imagine process metrics can be useful for others too.

I think --monitoringServerFeatures=process-metrics would be best (ideally we'd have more finegrained settings but I think this fits the current setup well enough), feel free to open a PR 🙂 I might get around to this at some point as well if not.

Note that we have big refactoring ahead (#1333) so might be best to wait for this first.