fix(agent-actions): owner-exemption logic does not recognize ADMIN_GITHUB_LOGINS

[JSONbored]

Parent: #1936

Problem

The main planner's close-eligibility gate (src/settings/agent-actions.ts:315-320) computes isContributor = !authorIsOwner && !authorIsAutomationBot, where authorIsOwner (src/queue/processors.ts:1635-1637, duplicated at 3359-3364) is a literal case-insensitive match against the repo-owner segment of repoFullName. This exemption set does not include the fleet-operator ADMIN_GITHUB_LOGINS allowlist — which is honored as a maintainer-trust signal in the separate reopen-reclose path (hasMaintainerPermission, processors.ts:7006-7008: login === repoOwner || admins.has(login)), and was explicitly unified across the codebase in a prior PR specifically so it would be "honored everywhere." It wasn't threaded into the primary close-eligibility computation.

Failure scenario: an operator/admin login (present in ADMIN_GITHUB_LOGINS but not the literal repo-owner account) opens a PR on a gate-managed repo. If that PR trips a heuristic close condition (red CI, gate blocker, base conflict) or an erroneous blacklist match, the planner will close it — even though the same login is treated as a trusted, reopen-immune maintainer elsewhere in the same codebase. A genuine, low-likelihood but real cross-path authorization inconsistency.

Requirements

• The same "trusted operator" identity must be honored consistently across every close-eligibility check in the codebase, not just the reopen-reclose path.

Deliverables

• Extend the planner's input with an authorIsAdmin (or fold into a broader authorIsMaintainer) field, computed using the same parseGitHubLoginList(env.ADMIN_GITHUB_LOGINS) helper already used by hasMaintainerPermission.
• Thread it into isContributor/closeEligible/blacklistContributor in agent-actions.ts, and apply the identical fix to the duplicate authorIsOwner computation in the draft-dodge path (processors.ts:3359-3369).
• Add a regression test in test/unit/agent-actions.test.ts asserting an admin-login (non-owner) author is not close-eligible under failing CI / a conflict / a blacklist match, mirroring the existing authorIsOwner tests.

Acceptance criteria

• A PR authored by an ADMIN_GITHUB_LOGINS member (not the literal repo owner) is exempt from heuristic/blacklist auto-close, matching its exemption from forced reopen-reclose.
• Non-admin, non-owner contributor PRs are unaffected.

Expected outcome

One consistent trusted-operator identity model across every actuation path, instead of two independently-implemented and drifting definitions of "maintainer."

[linear-code]

JSO-2235