granularityHierarchies response bloat when CUBEJS_DEV_MODE is set to TRUE. Over 100x size in response bodies.

[BeautyFades]

Describe the bug
If CUBEJS_DEV_MODE=true, responses from the cubejs-api/v1/load endpoints return really large objects, often 100x in size compared to if CUBEJS_DEV_MODE=false.

To Reproduce
Steps to reproduce the behavior:

1. Spin up a minimal Cube instance connected to a database. Set CUBEJS_DEV_MODE=true;
2. Make a simple request to cubejs-api/v1/load;
3. Check response size;
4. Tear Cube down, now set CUBEJS_DEV_MODE=false;
5. Make the same request to cubejs-api/v1/load;
6. Check response size.

Expected behavior
I know CUBEJS_DEV_MODE is technically for testing purposes, but when setting up local or QA environments we have that flag set to TRUE. However, it hogs browsers down by transferring unholy amounts of data between the Cube server and the client.

Screenshots
Response size on my QA instance (set to DEV_MODE) for a query:

Same query, on a PROD instance (which is not in DEV_MODE):

Minimally reproducible Cube Schema
I am using ClickHouse as the engine, so pardon the sql formatting. GPT can convert SELECT statement to work on other engines.

cubes:
  - name: TestCube
    sql: |
      SELECT toString(1) AS id, 'Alice' AS name, toString(toDate('2025-01-01')) AS created_at
      UNION ALL
      SELECT toString(2), 'Bob', toString(toDate('2025-02-01'))
      UNION ALL
      SELECT toString(3), 'Charlie', toString(toDate('2025-03-01'))

    joins: []

    dimensions:
      - name: id
        sql: id
        type: number
        primary_key: true
        shown: true

      - name: name
        sql: name
        type: string

      - name: createdAt
        sql: created_at
        type: time

    measures:
      - name: count
        type: count

    pre_aggregations:
      []

Version:
Tested with both v1.3.15 and v1.3.78 using ClickHouse as the engine.

Additional context
Upon further inspection, the bloated responses that return when CUBEJS_DEV_MODE=false contain information regarding every other Cube's granularityHierarchies.

This issue happens no matter what the data types included in the requested query are. You can request strings and granularityHierarchies will still return every single other Cube's granularities, so this happens even if the requested dimension or measure fields are NOT date fields.

Image of the response size while requesting a single dimension from the provided TestCube

Same query with DEV_MODE set to FALSE: