[Improve]:Improve defensive handling of nullable GraphQL fields in dashboard processing

[SHUBHANSHU602]

The dashboard script accesses several nested GraphQL fields directly, for example:

discussion.author.login discussion.comments.nodes.reduce(...) discussion.reactions.totalCount issue.labels!.nodes

Some fields (e.g. author, labels, connection nodes) may be nullable in the GitHub GraphQL schema depending on:

Deleted users
Partial data
API edge cases

In a few places, non-null assertions are used:

While this works under normal conditions, the script runs in CI.
If GitHub returns an unexpected null for any nested field, the script could throw:

Cannot read properties of null

Which would cause dashboard generation to fail.

Expected Behavior

The script should defensively handle nullable fields using optional chaining or fallback values, for example:

issue.labels?.nodes ?? [] discussion.author?.login ?? 'unknown' discussion.comments?.nodes ?? []

This would:

Improve robustness of the dashboard generator
Prevent CI failures due to unexpected null values
Align better with TypeScript’s null-safety guarantees

Steps to Review

Please review field access in:
scripts/dashboard/build-dashboard.ts
Especially inside processHotDiscussions and mapGoodFirstIssues