Forwarding trusts only a person's edits, not a GitHub App with an instructor's login #75

Outcome

Forwarding trusts an edit only when a person made it. A GitHub App whose GraphQL login matches an instructor no longer passes as that instructor when it edits the issue body or an instructor's comment during a build.

Acceptance criteria

• ACTIVITY_QUERY in apps/server/src/factory/tracker/github.ts asks for __typename on editor and on every userContentEdits editor. COMMENT_EDITOR_QUERY already does.
• activitySince checks body edits with isHumanInstructor (apps/server/src/factory/tracker/approvalHistory.ts): the last editor and every edit after since. An edit by an actor that is not a User gives no body edit.
• checkEdits uses isHumanInstructor for the last editor and for every history entry, so a comment edited by an App is dropped with reason edited-by-other and reported once.
• The forwarding fixtures in github.test.ts carry __typename: "User" on human editors. New tests cover a body edit and a comment edit by a Bot whose login matches an instructor.
• Comment authorship from the REST listing (user.login) is unchanged.

Depends on

• Forward instructor comments and edits into a running session #22

Notes

Found in review of PR #73 (finding f2) and settled there as a faithful port: softfac bf273a1's activity_since matches editors with is_instructor (login only). softfac's own is_human_instructor says why that falls short: "A GitHub App's GraphQL login can lack the [bot] suffix, so a login that matches an instructor is not enough." The approval and feedback paths already follow that rule. This change brings forwarding in line with it.

Leave at factory:proposed until the fork's factory watches this repo (same as #22).