Retain interactions and queries per UI in development mode

The insight collectors keep an interaction only when it fails or exceeds the 1 s UX budget, and JDBC statements are never kept as records: the row-counting data source feeds a timer, a summary and a span, nothing else. A healthy 300 ms click that ran 30 queries lands in the timers and is gone. That is exactly the case a developer wants to see while working on a view.

In development mode only:

• Keep every interaction in a per-UI ring buffer with a stable interaction id. The collector threshold is already a constructor parameter, so this is a second collector instance with threshold 0, not a redesign.
• Attach data-provider queries and JDBC statements as children of the current interaction, with parameterised SQL, row count, duration and start offset. The data source wrapper already sees the SQL and the row count at result-set close; it needs a second sink next to the span. Statement capture defaults to on here, since the SQL never leaves the developer's machine.
• Count identical statements per interaction. Grouping on the parameterised SQL alone is enough to surface N+1 patterns.
• Expose the UI state sample for one UI on demand. UiStateSampler already measures a single UI; only fleet aggregates are published today.
• Evict the buffer when the UI detaches, and cap it per UI.
• Add a dev-tools command that returns the buffer for the calling session and UI only. The session is available inside a dev-tools handler, and records already carry session and UI ids.

Nothing here is created in production mode.

Start by tracing the insight collectors and their constructor threshold, then inspect the row-counting data source, UiStateSampler, and the dev-tools handler. Verify how session and UI IDs flow through these entry points before defining the per-UI buffer boundaries. Done means development-only interaction retention, grouped query and statement records, on-demand UI sampling, detach eviction and per-UI caps, with session/UI-scoped retrieval.