#15611: fix(gateway): invalidate hook transform cache on config reload

## Summary - The `transformCache` Map cached loaded transform functions forever - Editing hook transform JS files on disk had no effect until gateway restart - Node.js `import()` also has its own module cache ## Fix - Clear `transformCache` when hook mappings are re-resolved during config reload - Use cache-busting query parameter on dynamic `import()` URL to bypass Node.js module cache ## Test plan - [x] Existing hooks-mapping tests pass <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR addresses hot-reloading of hook transform modules by (1) clearing the in-memory `transformCache` when hook mappings are re-resolved and (2) adding a cache-busting query param to the dynamic `import()` URL to bypass Node’s own module cache. It also aligns config default application in `readConfigFileSnapshot` and adds a test ensuring `clearCommandLane` rejects queued promises. Main concern is the new `?t=${Date.now()}` import specifier: combined with clearing `transformCache` on reload, repeated config reloads can accumulate distinct module entries in Node’s module map over time. There’s also an unused exported `clearTransformCache()` helper that currently isn’t wired into the reload path. <h3>Confidence Score: 3/5</h3> - This PR is close to safe but has a real risk of memory growth in long-running gateways with repeated config reloads and hook transforms enabled. - The functional intent (hot-reloading hook transforms) is clear and tests were added for the command queue behavior, but the `import()` cache-busting strategy uses ever-unique module specifiers (`?t=${Date.now()}`), which can accumulate in Node’s module cache across reloads once `transformCache` is cleared. Fixing the import invalidation approach (and/or limiting reload frequency/uniqueness) would improve safety. - src/gateway/hooks-mapping.ts _{Last reviewed commit: 234e8cf} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->