Fix warmed renderer performance measurement

[danballance]

Summary

• measure only long tasks produced after the warmed renderer observer is installed
• assert directly that the measured interaction produces no long tasks

Root cause

The performance observer used buffered: true, which replayed Electron startup long tasks that occurred before the observer was installed. On GitHub runners those unrelated startup entries lasted 70–77 ms, causing the warmed-renderer test to fail.

Impact

The E2E performance check now measures the intended editor fill, flush, and activity-injection workload without including renderer startup noise.

Validation

• npm run lint
• npm run build
• git diff --check

The focused Electron test could not run in the local container because it lacks Xvfb and libglib-2.0.so.0; the GitHub workflow provides the required Linux runtime.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric	Results
Complexity	0
Duplication	0

View in Codacy

AI Reviewer: first review requested successfully. AI can make mistakes. Always validate suggestions.

_{TIP This summary will be updated as you push new changes.}

[codacy-production]

Pull Request Overview

The implementation successfully isolates interaction performance from Electron startup noise by disabling buffered observer entries, meeting the core requirements for accurate measurement. However, the strict assertion requiring zero long tasks (tasks > 50ms) introduces a risk of flakiness in shared CI environments due to potential CPU contention and the asynchronous nature of PerformanceObserver notifications. The code is technically up to standards, but consideration should be given to environment-induced noise.

Test suggestions

• Initialize PerformanceObserver for 'longtask' without the 'buffered' flag to ignore pre-existing entries
• Verify the test assertion fails if any long task entries are recorded (longTasks count > 0)

_{TIP Improve review quality by adding custom instructions
TIP How was this review? Give us feedback}

[codacy-production]

_{🟡 MEDIUM RISK}

Suggestion: This assertion is strictly sensitive to CI environment noise and may be flaky. Consider allowing a small budget for long tasks or ensuring a settlement period (e.g., waiting for the main thread to be idle) before results are collected to ensure all asynchronous PerformanceObserver notifications have been processed.