github-types.ts: GitHubIssue.assignees and labels arrays are not typed as nullable, inconsistent with other nullable fields

Open src/prompt-generators/github/github-types.ts and compare GitHubIssue.assignees and labels with the existing nullable user, assignee, and milestone fields. Update the two array field types to include null, then confirm the existing optional-chaining callers in src/prompt-generators/github.ts remain compatible. Done means both fields match the GitHub API nullability without runtime changes.

Observed behavior

In src/prompt-generators/github/github-types.ts, the nullable fields on GitHubIssue are inconsistent in how they handle "the GitHub API can send null":

export interface GitHubIssue {
  // ...
  readonly user?: GitHubUser | null;          // includes | null
  readonly assignee?: GitHubUser | null;      // includes | null
  readonly assignees?: ReadonlyArray<GitHubUser>;            // no | null
  readonly labels?: ReadonlyArray<GitHubLabel | string>;     // no | null
  readonly milestone?: GitHubMilestone | null; // includes | null
  // ...
}

GitHub's REST API schema for the Issue object marks both assignees and labels as nullable: true. So at runtime these fields can be present and set to null (not just undefined). The other nullable fields (user, assignee, milestone) correctly model that with | null. assignees and labels do not.

This does not currently cause a runtime bug because the consumers in src/prompt-generators/github.ts use optional chaining, which short-circuits on both null and undefined:

assignees: issue.assignees?.map(user => user.login).join(', ') ?? '',
// and in labelNames:
issue.labels?.map(label => /* ... */) ?? []

But the type lies to any caller who reaches for these fields without ?. - for example for (const a of issue.assignees ?? []) is safe, while if (issue.assignees) for (const a of issue.assignees) would still be safe because null is falsy, but const xs = issue.assignees as ReadonlyArray<GitHubUser> followed by xs.map(...) would crash. TypeScript will not warn about that, because the type says assignees is either an array or undefined.

Expected behavior

assignees and labels should match the GitHub API and the convention already used for other nullable fields in this same interface:

readonly assignees?: ReadonlyArray<GitHubUser> | null;
readonly labels?: ReadonlyArray<GitHubLabel | string> | null;

This is purely a type-level fix; no runtime change is needed.

Minimal reproduction

Compare the field signatures in src/prompt-generators/github/github-types.ts against GitHub's published Issue object schema. The mismatch is internal to the file - user/assignee/milestone already do the right thing.

Suggested fix

Add | null to the assignees and labels fields in GitHubIssue. No runtime changes required; existing callers already handle null correctly via ?..