fix(history): truncation banner quotes the wrong cap and a failed class listing does not set truncated #686

Summary

Two small gaps left by #632 PR1 (PR #684): the History truncation banner quotes the wrong cap, and a failed class listing hides rows without raising truncated.

Current behaviour

1. frontend/src/history.ts:~396 renders "capped at ${executions_limit} pending, failed or other non-completed executions". After PR fix(history): fetch actionable executions separately so terminal rows cannot starve them #684, executions_limit (100) caps only the terminal class; actionable rows (pending, notified, scheduled, approved, running, paused) have a separate cap of MaxListLimit (1000). When only the actionable class hit its cap the banner still says 100.
2. fetchExecutionsByClass (internal/api/handler_history.go) logs a listing error and skips that class; truncated stays false. If the actionable query fails, pending approvals disappear with no signal in the response (no worse than before PR fix(history): fetch actionable executions separately so terminal rows cannot starve them #684, but it is the one remaining silent path).

Steps to verify the gap

1. Return 1000 actionable rows from the store: truncated is true but the banner text says 100.
2. Make the actionable GetExecutionsByStatuses call return an error: the response has no pending rows and truncated is false.

Expected behaviour

1. The banner states the cap that was actually hit (or the API exposes both caps).
2. A class listing error makes the response flag incomplete results (for example truncated=true), so the UI shows its banner.

Proposed fix

1. HistoryResponse gains the actionable cap (or the banner text drops the number); update renderTruncationNotices and frontend/src/__tests__/history-truncation-notice.test.ts; fold into the frontend PR feat(frontend): Load more on the History view, Approval Queue from all loaded pages #676 (frontend build is serialized fleet-wide).
2. In fetchExecutionsAsHistory set the cap signal when either fetchExecutionsByClass errors; add a test next to TestHandler_getHistory_ClassListingErrorKeepsOtherClass.

References

PR #684 review by cc-cli-w2 (notes A1 and R1), parent #632, umbrella #248, related #676 and #680. Severity: low.