feat(api): page the History view past the first limit rows (offset, has_more) #674

Summary

Follow-up to #632 (PR1 + PR2 make sure a pending approval is never hidden behind other rows). The History API still has no way to page past the first limit rows.

Current behaviour

GET /api/history returns at most limit (default 100, max MaxListLimit 1000) rows per source with truncated set when a cap was hit (#630). There is no offset, so rows past the cap are unreachable.

Steps to verify the gap

Create more than 100 completed-with-error / terminal executions in the selected date range; the oldest ones never appear, and the UI can only say "narrow the date range".

Expected behaviour

offset query parameter and has_more in the response; stable ordering so pages never duplicate or skip rows.

Proposed fix

• parseHistoryFilters (internal/api/handler_history.go): parse offset >= 0, enforce offset+limit <= MaxListLimit.
• Fetch offset+limit+1 per source, merge-sort, slice; tie-break orders (scheduled_date DESC, execution_id DESC) for executions and (timestamp DESC, purchase_id DESC) for history.
• HistoryResponse (internal/api/types.go) gains offset, has_more; document in internal/api/openapi.yaml (/api/history).
• Tests: internal/api handler tests with a scoped and an unscoped user; pgxmock SQL-shape tests in internal/config.

References

Parent #632, umbrella #248, #630 (truncation signal). Severity: medium. Depends on #632 PR1/PR2.