[Dashboards] Improve performance of burndown/burnup queries

[DavidDudas-Intuitial]

Summary

Two problems found while reviewing the deliverable burndown/burnup queries on the Delivery Metrics dashboard:

• The burnup queries (Sprint_Burnup_by_issues, Sprint_Burnup_by_points, Deliverable_Burnup_Issue_Count, Deliverable_Burnup_Points) wrongly compute total_remaining = opened - closed, using the burndown formula because of a copy/paste error, so the burnup charts render as a single declining line identical to burndown instead of two series that both climb toward total scope.
• The deliverable burndown/burnup queries recursively walk gh_issue.parent_issue_ghid and look up the latest deliverable/epic mapping via gh_deliverable_quad_map/gh_epic_deliverable_map, but none of these columns have a supporting index, so every query execution falls back to a full table scan or sort.

Acceptance criteria

• Burnup queries show two independent series (total_scope, total_completed) that both climb toward total scope, instead of a single subtracted total_remaining
  • Sprint_Burnup_by_issues
  • Sprint_Burnup_by_points
  • Deliverable_Burnup_Issue_Count
  • Deliverable_Burnup_Points
• Add indexes to speed up the deliverable burndown/burnup queries
  • gh_issue(parent_issue_ghid)
  • gh_deliverable_quad_map(deliverable_id, d_effective)
  • gh_epic_deliverable_map(epic_id, d_effective)