Add real-time speed trend chart to all games via centralized service

[Copilot]

Field of View had a speed threshold trend chart during gameplay; no other game did. This adds equivalent charts to all remaining games using a shared service to avoid duplicating chart geometry and DOM update logic.

Centralized Service

app/components/trendChartService.js (pre-existing, now used by all games) exposes two functions:

• buildPolylinePoints(values) — scales an arbitrary numeric array into SVG polyline coordinates
• renderTrendChart(els, values, currentValue) — updates polyline, empty-state, and latest-value elements

// Each game's index.js calls this after every round:
export function updateTrendChart() {
  renderTrendChart(
    { lineEl: _trendLineEl, emptyEl: _trendEmptyEl, latestEl: _trendLatestEl },
    game.getSpeedHistory(),
    game.getCurrentIntervalMs(),
  );
}

Per-game changes (object-track, orbit-sprite-memory, otter-stop, sound-sweep)

Each game received identical structural changes:

game.js

• speedHistory[] module-level array, reset in initGame()
• Push to speedHistory after staircase adjustment in the scoring function
• getSpeedHistory() export returning a defensive copy

index.js

• Import renderTrendChart from trendChartService
• DOM refs for #<id>-trend-line, #<id>-trend-empty, #<id>-trend-latest
• updateTrendChart() called after each round result and in reset()

interface.html

• <section class="game-trend"> with SVG polyline chart using shared CSS classes

Speed metrics tracked

Game	Metric
object-track	speedPxPerSec (px/s)
orbit-sprite-memory	displayDurationMs
otter-stop	intervalMs
sound-sweep	sweepDurationMs

Bug fix

field-of-view/render.js renderThresholdTrend was passing formatMs(currentSoaMs) (a formatted string) as the currentValue fallback while populated entries display raw numbers — inconsistent. Changed to pass the raw number; the "ms" label is static HTML.

[acrosman]

Review all your new tests. Make sure each test tests something (code, functions, scenarios, etc) unique from other tests. Overly large test files are hard to maintain and cause errors. Ensure the coverage meets project requirements without unless extra tests.

[acrosman]

Three tests for blank inputs is overkill in this context. [] and null seem more than sufficient.

[Copilot]

Removed the undefined test in 7b62a17. The [] and null tests are kept since they exercise different branches of if (!values || values.length === 0).

[acrosman]

Why are we again testing blank inputs? Is there any valid reason to test this again?

[Copilot]

Removed the "returns empty array before any rounds" test from all 7 game.test.js files in 7b62a17. The beforeEach(() => { initGame(); }) and the "resets to empty after initGame" test already cover that state.

[acrosman]

Why are we again testing blank inputs? Is there any valid reason to test this again? Review all places you run tests for blank and make sure they are useful. Extra tests, that increase the complexity and upkeep on the testing process aren't useful and should be removed.

[Copilot]

Done in 7b62a17 — removed the redundant "empty before any rounds/trials" test from all 7 game test files and the undefined blank-input test from trendChartService.test.js.

[Copilot]

Review all your new tests. Make sure each test tests something (code, functions, scenarios, etc) unique from other tests. Overly large test files are hard to maintain and cause errors. Ensure the cove...

Trimmed in 7b62a17: removed 8 tests total — the undefined edge case from trendChartService.test.js (kept only [] and null) and the "returns empty array before any rounds/trials" test from all 7 game.test.js files, since that state is already covered by the initGame reset test and beforeEach. Coverage thresholds still pass (100% functions, 1306 tests across 34 suites).

Changes complete