Feature: Integrate live graph benchmarking with the core application (graph overlay, analyzer, history) #39

Problem Statement

PR #37 added live graph benchmarking (/benchmark-live, SSE streaming of per-second samples, one-click index optimization), but it currently behaves like a standalone demo rather than a part of the application:

1. Demo-only. The page and the /api/demo/* endpoints are served only with DEMO_MODE=true and a live_demo section. Scenarios, graph topology and the "suggested index" are hand-written configuration. A user with their own performance.benchmarks.custom_queries cannot run them from the UI.
2. Not connected to the transformed graph. The live graph nodes come from live_demo.topology, not from the Neo4j graph or the transformation rules. The main visualization (/) has a performance overlay (/api/performance/data/graph, visualization.js) that matches Neo4j node ids to table-derived ids heuristically, and benchmark samples never reach it.
3. Two parallel performance-graph models and transports. GraphPerformanceMapper / RealtimePerformanceMonitor (WebSocket /ws/performance, based on Performance Schema) and ports.LiveSample / LiveGraph (SSE) describe the same thing (table heat, edge latency and load) twice.
4. Simulated metrics. bootstrap.InitAll always starts SimpleMetricsInjector with SimulationMode: true, which writes fake metrics into Neo4j relationships, while real measured data now exists.
5. No history. Samples are kept in an in-memory ring buffer per run and are lost on restart. Results are persisted by FileBenchmarkResultStore, but the UI keeps only Run A/B in memory, so past runs cannot be reopened or compared after a reload.
6. Suggestions are not connected. "Apply suggested index" is a static configuration entry, while PerformanceAnalyzer already produces index suggestions.
7. sysbench does not stream, although SysbenchDefaults.ReportInterval exists in the configuration model and is unused.
8. MySQL-only pieces. The index state check (indexExists in internal/interfaces/api/demo_handlers.go) reads information_schema.statistics.

Proposed Solution

Integrate in phases, each shippable on its own:

1. Generic mode (no DEMO_MODE). Add GET /api/performance/benchmarks/query-sets and let /benchmark-live pick any configured custom query set. Derive the topology from the query tables and schema discovery (foreign keys, as used by analyze/transformation rules), keeping live_demo.topology only as an override. The index apply/revert endpoints stay DEMO_MODE-only.
2. One model, one id convention, shared UI. Unify on a single performance-graph model (map LiveGraph onto PerformanceEnhancedGraph/PerformanceGraphData, or the reverse) with ids that match the Neo4j nodes. Optionally publish live samples on a benchmark topic of /ws/performance. Extract the D3 graph renderer from benchmark-live.js into a shared module used by /benchmark-live, /performance and the main visualization.
3. Live overlay on the main graph. Add a "Live benchmark" toggle to / that colours the real Neo4j nodes and relationships with live heat, mapping table names to nodes through source_table of the transformation rules.
4. Persistence and history. Persist samples together with results, serve GET .../{id}/samples from the store after a restart, and add a run history list with reopen and a compare picker to the UI. Align with the snapshot work in 📸 Performance Graph Snapshot System #17 / Performance Graph Snapshot System #20.
5. Analyzer-driven suggestions. Build the suggested optimization from PerformanceAnalyzer index suggestions instead of static configuration, keeping the CREATE INDEX / DROP INDEX allowlist and the DEMO_MODE guard. Replace the simulated SimpleMetricsInjector data with real data, or remove it.
6. Tool and database coverage. Stream sysbench runs through --report-interval into the same live view, and make the index inspection database-agnostic (for example pg_indexes for PostgreSQL).

Alternative Solutions

Keep live benchmarking as a documented demo feature. This is cheaper, but it leaves the original goal of #12 (benchmark integration with graph load visualization) unmet and keeps the duplicated models and transports.

Use Case

A user transforms their MySQL schema to Neo4j, opens the graph, runs their own query set and sees live heat on the same nodes they are already exploring, then reopens last week's run to compare it with today's.

Priority Level

Important

Implementation Ideas

• Keep handlers thin and the model in internal/application/ports, in line with the existing DDD layers; the id mapping can reuse SourceConfig.SourceTable from internal/domain/models.
• Align the live_demo section with the configuration consolidation in Configuration Consolidation and Standardization #23.
• Split into one sub-issue per phase once scope and order are agreed.
• Tests: golden tests for the id mapping, SSE/WebSocket integration tests, and a browser test of the overlay toggle.

Additional Context

Related: #12, #17, #20, #21 (Grafana Plugin and Monitoring Systems Integration, could reuse the unified model), #23. Companion issue: #38 (headless bench CLI). Needs discussion on scope and order before implementation.