Dev mode: `/cubejs-api/v1/meta` hangs indefinitely on any data model edit made after a query has run (regression in 1.7, works in 1.6)

## Summary

In development mode, editing a data model file causes `/cubejs-api/v1/meta` to block forever — but only if a query has been executed since startup. The Playground sits on "Loading meta information..." permanently. Only a restart clears it.

Both conditions are required, which makes it look intermittent.

## Reproduction

1. Start Cube in dev mode with a single cube (`sql_table`, a few dimensions, a `count` measure).
2. Wait for `/cubejs-api/v1/meta` to return 200.
3. Run any query via `/cubejs-api/v1/load`.
4. Make any content change to the model file — appending a comment line is enough.
5. Request `/cubejs-api/v1/meta`.

**Expected:** meta returns the recompiled model.
**Actual:** the request never returns.

## Isolation

| sequence | `/v1/meta` result |
| :---- | :---- |
| edit model, no query run since startup | 200 in 0.8s |
| query only, no edit | 200 in 0.009s |
| **query, then edit model** | **hangs indefinitely** |

Additional observations during the hang:

- Container CPU ~1%, so it is not a spin loop.
- `/playground/files` and `/playground/context` still respond in ~15ms, so the event loop is not blocked.
- No SQL is issued for the pending refresh cycle; logs show `Previous interval #N was not finished with 30000 interval` repeating.
- It never recovers. Observed still hanging after several minutes.
- `touch` on the model file (mtime only, no content change) does **not** trigger it.

## Versions

| image | result |
| :---- | :---- |
| `cubejs/cube:v1.6.72-jdk` | works — repeated query→edit cycles reload in ~0.7s |
| `cubejs/cube:v1.7.0-jdk` | hangs |
| `cubejs/cube:v1.7.19-jdk` | hangs |
| `cubejs/cube:v1.7.25-jdk` | hangs |

v1.7.0 is already affected, so this appears to span the entire 1.7 line rather than being a late regression.

## Ruled out

None of these changed the behaviour:

- Moving Cube Store's data off the Docker bind mount (mounting only `model/` rather than the project root)
- `CUBEJS_TRANSPILATION_WORKER_THREADS=false`
- `CUBEJS_SCHEDULED_REFRESH_TIMER=false` together with `CUBEJS_REFRESH_WORKER=false`
- An explicit cube-level `refresh_key` with a long `every`
- `CUBEJS_CACHE_AND_QUEUE_DRIVER=memory`
- `CUBEJS_DB_MAX_POOL=20` with `CUBEJS_CONCURRENCY=4`
- `sql:` instead of `sql_table:`

## Environment

- Docker image `cubejs/cube:-jdk`, `platform: linux/amd64` on Apple Silicon (Docker Desktop, macOS)
- `CUBEJS_DEV_MODE=true`
- Driver: `databricks-jdbc`

## Caveat

Reproduced only against `databricks-jdbc`, where each query takes ~5–9s. I have not verified whether a fast-responding driver also reproduces it, so query duration may be a factor.