Harden legacy dashboard GitHub API error handling

[Copilot]

The legacy dashboard’s GitHub API client only treated non-OK responses as a generic failure, leaving important HTTP cases, network failures, and malformed responses under-specified. This change makes those failure modes explicit so the dashboard degrades predictably instead of surfacing uncaught exceptions.

• API error classification

  • Map common GitHub API statuses to clearer errors: 401, 403, 404, 422, 429, and 5xx
  • Preserve response-provided error details when available
  • Attach HTTP status to thrown errors for downstream handling

• Network and response hardening

  • Distinguish fetch failures from HTTP failures
  • Convert aborts/timeouts into explicit request timeout errors
  • Treat invalid JSON bodies as a separate parse failure instead of leaking raw exceptions

• Legacy asset parity

  • Apply the same behavior to both checked-in dashboard copies so the root legacy page and the published legacy mirror stay aligned

• Regression coverage

  • Add focused tests for:
    • not found / server-side HTTP failures
    • network fetch failures
    • invalid JSON responses

if (!response.ok) {
  const httpError = new Error(`${this.getStatusMessage(response.status)}${details}`);
  httpError.status = response.status;
  throw httpError;
}

try {
  return await response.json();
} catch (error) {
  const parseError = new Error(`GitHub API returned invalid JSON for ${endpoint}`);
  parseError.cause = error;
  throw parseError;
}

[cywf]

Closing this draft as stale/superseded during CYWF portfolio cleanup. The current project-first portfolio direction is covered by later overhaul work; please reopen or file a fresh PR if a specific change is still needed.