fix: make TUI charts fill available width on wide terminals

[gnodet]

Summary

Claude Code on behalf of Guillaume Nodet

Charts previously used a fixed 60-point history buffer which left significant empty space on wide terminals. This PR makes charts dynamically size to fill the available width.

Changes

• MetricsCollector: Increase history buffer caps from 60 to 300 points so enough data accumulates for wider terminals
• OverviewTab: Increase MAX_SPARKLINE_POINTS from 60 to 300 (bar chart renderPoints was already computed dynamically from available width)
• EndpointsTab: Increase MAX_CHART_POINTS from 60 to 300 and compute renderPoints dynamically from the chart area width in all three chart methods (renderEndpointFlow, renderSingleEndpointChart, renderPayloadSizeChart)

Test plan

• Build passes locally
• Verified visually — sparklines and bar charts now fill their panels on wide terminals
• CI passes

🤖 Generated with Claude Code

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[github-actions]

🧪 CI tested the following changed modules:

• dsl/camel-jbang/camel-jbang-plugin-tui

All tested modules (2 modules)

• Camel :: JBang :: Plugin :: TUI
• Camel :: Launcher :: Container

---

⚙️ View full build and test results

[davsclaus]

Nice cleanup — the dynamic sizing logic is correct and the buffer increase is well-scoped.

One thing I noticed: CircuitBreakerTab has the same fixed-60 chart sizing (MAX_CHART_POINTS = 60 at line 52, renderPoints = MAX_CHART_POINTS at line 355) that this PR fixes in EndpointsTab. The CB history buffer in MetricsCollector is already bumped to 300 (it goes through recordEndpointSample → MAX_ENDPOINT_CHART_POINTS), but the render side is still hardcoded. Could be addressed in a follow-up.

Also a pre-existing nit: OverviewTab declares its own MAX_SPARKLINE_POINTS instead of referencing MetricsCollector.MAX_SPARKLINE_POINTS — they could drift.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

[davsclaus]

CircuitBreakerTab also has MAX_CHART_POINTS = 60 and a hardcoded renderPoints = MAX_CHART_POINTS (line 355) — same pattern this PR fixes here. The MetricsCollector buffer is already bumped (CB history uses MAX_ENDPOINT_CHART_POINTS via recordEndpointSample), so only the render side needs the same Math.min(MAX, Math.max(2, width - 6)) treatment. Could be a follow-up.

[gnodet]

Claude Code on behalf of Guillaume Nodet

Good catch! Applied the same treatment to CircuitBreakerTab: bumped MAX_CHART_POINTS to 300, computed renderPoints dynamically from vSplit.get(1).width() - 6, and made the x-axis labels dynamic too. See 398034a.