fix(dashboard): use mirror data for issues trend

[statxc]

Summary

The dashboard's "Issues Opened / Resolved" trend graph was sourced from /issues, which only returns bounty-backed issues. The overview cards right above it use miner aggregates instead, so the two halves of the page disagreed loudly — 33 issues in the chart vs. ~1,000 in the cards.

This PR repoints the trend graph at the same population the cards use: a per-miner fan-out to the mirror's /api/v1/miners/:id/issues via the existing useMinersIssues helper, flattened and deduped client-side.
No backend changes.

Changes

• src/api/MinerApi.ts — useMinersIssues accepts an optional since ISO timestamp, forwarded to the mirror as a query param.
• src/pages/dashboard/dashboardData.ts — buildDashboardTrendData now consumes MinerIssue[]. Two small helpers added:
  • flattenMinerIssues — dedupes responses by (repo, number) so an issue surfaced under multiple miners is counted once.
  • isResolvedMinerIssue — state === 'CLOSED' && state_reason === 'COMPLETED' (NOT_PLANNED / TRANSFERRED are excluded, matching GitHub's "completed" semantic).
  • getMirrorSinceParam — emits since only for the all range so the cache key stays stable across 1d/7d/35d.
• src/pages/dashboard/useDashboardData.ts — fans out only to miners with any issue activity to bound the parallel-request count, then flattens through flattenMinerIssues.
• src/tests/dashboardIssuesTrend.test.ts — 13 unit tests covering the trend builder, the since cache-key behavior, dedup across fan-out responses, and the resolved predicate.

Known caveat

Aggregates and mirror fan-out won't agree to the last digit. The aggregate counters include issues a miner solved (authored by someone else); the mirror endpoint returns issues a miner authored. The trend graph wants the latter, so this is the right source — but the overview-card totals will still read higher.

Related Issues

Fixes #1000

Type of Change

• Bug fix
• New feature
• Refactor
• Documentation
• Other (describe below)

Screenshots

Checklist

• New components are modularized/separated where sensible
• Uses predefined theme (e.g. no hardcoded colors) — no styling changes
• Responsive/mobile checked — data-layer change only, no layout impact
• Tested against the test API
• npm run format and npm run lint:fix have been run
• npm run build passes
• Screenshots included for any UI/visual changes