Honor query parameters in handleGetChartData and implement getChartData

## Context

#75 asked for query parameters to be honored in both of the performance REST handlers. PR #83 implements `start` and `end` for `handleGetPerformance` but leaves `handleGetChartData` untouched. It still opens with `boost::ignore_unused(query)` and hardcodes a one hour window:

```cpp
auto chartData =
m_collector->getChartData(strategyId, metric, 3600000000000ULL); // 1 hour
```

So a request like `/api/v1/strategies//chart/pnl?range=900000000000` routes correctly (since #72) but always returns the same one hour window.

Worth noting: `PerformanceCollector::getChartData` is currently a stub that returns an empty vector, so the endpoint returns `[]` regardless. That can be filled in from the per strategy history that #83 adds (`m_performanceHistory`), since every `PerformanceData` snapshot already carries `timestamp`, `pnl`, `position`, `sharpeRatio`, etc.

## What to do

- Call `parseQueryString` in `handleGetChartData` and honor a `range` parameter (nanoseconds, same unit as the existing hardcoded value), or `start` and `end` as timestamp bounds. If both forms are given, `start`/`end` should win.
- Fall back to the current one hour window when no parameter is supplied so existing dashboard calls keep working, and ignore unknown parameters.
- Return `400` for malformed values or a reversed range, matching what #83 does for the performance endpoint.
- Implement `PerformanceCollector::getChartData` on top of the bounded history so the endpoint actually returns points for the supported metrics (`pnl`, `position`, `sharpe_ratio`, `max_drawdown`, `win_rate`, `total_trades`, `ml_accuracy`, `prediction_time`). Unknown metric should return `400` or an empty array, pick one and document it.
- Add unit tests for the parameter handling and for `getChartData` filtering, ideally through the same handler level seam requested in #83 so routing with query strings is covered too.

## Notes

Depends on #83 landing first (it introduces the history storage). Also keep in mind that nothing calls `VisualizationServer::recordPerformance` yet, so the chart data will be empty in a live run until a producer is wired up; that is tracked separately.

Refs: #75, #83, #72

Start with #83's performance history storage and the handler-level seam requested there, then inspect handleGetChartData, parseQueryString, and PerformanceCollector::getChartData. Verify parameter precedence, validation, metric filtering, and fallback behavior through unit tests; done means supported requests return bounded points and malformed or reversed ranges match the performance endpoint behavior.

Written by the indexing model from the issue text.