Editing large SQL queries can be slow to update when typing

Bug Description

A lengthy SQL query seems to show some very slow updates due to how we're processing the code every keystroke. I gathered up a performance report from Chrome while this was happening on a customer's query and ran it through Claude. Here's the output:

The subscriptions block at line 1913-1921 is the smoking gun:

  subscriptions(({ actions, values, cache }) => ({
      queryInput: (queryInput: string | null) => {
          cache.subqueryValidationCache?.clear()
          cache.updateActiveQueryDecoration?.()  // ← called synchronously on
  EVERY keystroke

  And updateActiveQueryDecoration calls splitQueries(fullText), then dispatches
  actions.setActiveQueryText(...) synchronously, then fires await
  buildSubquery() → await findInnermostSelectAtOffset() → await
  parseSelect(query) which runs the WASM HogQL parser on the full query text.

  Here's the full picture of what causes your 1608ms INP:

  ---
  Root cause

  subscriptions.queryInput calls cache.updateActiveQueryDecoration() on every
  single keystroke with no debounce (sqlEditorLogic.tsx:1921).

  updateActiveQueryDecoration does two things synchronously before yielding:
  1. splitQueries(fullText) — O(n) scan of the full query
  2. actions.setActiveQueryText(...) — a kea action dispatch that causes a
  synchronous cascade of 5-10 reducer evaluations and React re-renders (the GR →
   s → GR pattern in the profile)

  Then in the microtask queue (the 276ms RunMicrotasks block) it runs:
  - findInnermostSelectAtOffset → parseSelect(query) → WASM HogQL parser on the
  full query text

  The WASM parser (@posthog/hogql-parser, 003c6faa) is an ANTLR4 grammar
  compiled to WASM. It runs synchronously (WASM can't yield), and for a large
  query it takes ~200ms. This is what fills the RunMicrotasks window and
  prevents any paint.

  The comment on line 1920 says "decorations are cheap and visual — update
  immediately" — but they're not cheap. The WASM parse is the most expensive
  single operation on the main thread per keystroke.

  ---
  The fix

  The queryInput subscription at line 1921 should not call
  updateActiveQueryDecoration at all — the cursor position subscription (with
  its 150ms debounce at line 576) already handles this. Or at minimum, add a
  debounce matching the cursor handler:

  queryInput: (queryInput: string | null) => {
      cache.subqueryValidationCache?.clear()

      // Debounce — parseSelect (WASM) is called inside and takes ~200ms for
  large queries
      if (cache.activeQueryDecorationDebounceTimeout) {
          window.clearTimeout(cache.activeQueryDecorationDebounceTimeout)
      }
      cache.activeQueryDecorationDebounceTimeout = window.setTimeout(() => {
          cache.activeQueryDecorationDebounceTimeout = null
          cache.updateActiveQueryDecoration?.()
      }, 150)

  This alone should drop the INP from ~1600ms to ~20ms. The setActiveQueryText
  dispatch that happens inside updateActiveQueryDecoration will also be
  deferred, eliminating the synchronous kea cascade on every keystroke.

This is getting into performance optimization that I don't fully understand all the various details of and while debouncing makes a ton of sense I'm not going to claim to be an expert in this particular area so passing it up to the team to review :)

How to reproduce

1. User ticket has a great query
2. Editing is a bit of a topsy turvy rollercoaster of slow and fast redraws

Additional context

Debug info

- [ ] PostHog Cloud, Debug information: [please copy/paste from https://us.posthog.com/settings/project-details#variables or https://eu.posthog.com/settings/project-details#variables]
- [ ] PostHog Hobby self-hosted with `docker compose`, version/commit: [please provide]
- [ ] PostHog self-hosted with Kubernetes (deprecated, see [`Sunsetting Kubernetes support`](https://posthog.com/blog/sunsetting-helm-support-posthog)), version/commit: [please provide]

Start in the queryInput subscription and updateActiveQueryDecoration in sqlEditorLogic.tsx around lines 1921 and 1920, then compare them with the cursor-position subscription and its 150ms debounce around line 576. Reproduce the slow typing with the linked large query and inspect the Chrome performance report. Done means keystrokes no longer trigger the expensive full-query parsing on every update and editing responsiveness improves.