CXP-383 Support Last Log In w/ usage event feed for the Enterprise connector

[JavierCarnelli-ConductorOne]

Adds an opt-in usage event feed that streams each org's audit-log activity (web/API actions, excluding raw git operations and bot actors) as incremental usage events, letting the platform derive last-activity for members without a per-user API field to sync directly. The config field is intentionally hidden from this connector's CLI/GUI since it only applies to GitHub Enterprise audit-log access; the enterprise connector variant sets it directly on the shared config struct.

This feature is build to be used by baton-github-enterprise which vendors this connector.

[linear-code]

CXP-383

[github-actions]

Connector PR Review: CXP-383 Support Last Log In w/ usage event feed for the Enterprise connector

Blocking Issues: 0 | Suggestions: 1 | Threads Resolved: 0
Criteria: Criteria status: loaded .claude/skills/ci-review.md from trusted base 145e427ef1fa.
Review mode: incremental since e0fcb758
View review run

Review Summary

The new commit addresses two of the three findings from the previous review: usage_event_feed.go now bounds-checks cursor.OrgIndex before indexing cursor.Orgs, resetting to index 0 and discarding the stale per-org cursor, and usageEventFromAuditEntry dropped its unused time.Time return, with all three call sites and the tests updated accordingly (verified no other callers remain). The full PR diff was re-scanned for security and correctness — config field plumbing, EventFeeds gating, the feed implementation, and tests — and no new issues were found; the incremental artifact reports no dropped paths and no truncation. The third prior finding, the fabricated STATUS_OVERLIMIT rate-limit annotation, is still present at pkg/connector/usage_event_feed.go:160-166 and is carried below as a suggestion rather than re-flagged inline.

Security Issues

None found.

Correctness Issues

None found.

Suggestions

• pkg/connector/usage_event_feed.go:160-166 (carried over from the previous review, still open) — when a response carries no X-Ratelimit-* headers, extractRateLimitData (pkg/connector/helpers.go:184-228) returns Remaining: 0 / STATUS_OVERLIMIT, and because the tightest-limit comparison only looks at Remaining, that value always wins — so the 404/403 skip path can attach a spurious over-limit annotation to an otherwise successful pass.

Prompt for AI agents

Verify each finding against the current code and only fix it if needed.

## Suggestions

In `pkg/connector/usage_event_feed.go`:
- Around lines 160-166: `extractRateLimitData` (pkg/connector/helpers.go:184-228) returns a
  descriptor with `Remaining: 0` and `Status: STATUS_OVERLIMIT` whenever the response has no
  `X-Ratelimit-Remaining` header, because `r` stays at its zero value and the `if r <= 0`
  branch then marks it over-limit. The `tightestRateLimit` selection in ListEvents compares
  only `rl.GetRemaining()`, so that fabricated zero always beats any real value and becomes
  the rate-limit annotation returned for the whole call — including on the 404/403
  skip-and-continue path, where the request merely lacked audit-log permission and was not
  rate limited. Only use a rate-limit reading when the headers were actually present:
  either skip the update when the `X-Ratelimit-Remaining` header is empty, or ignore
  descriptors whose `Limit` is 0 (no headers present) so a header-less response cannot win
  the tightest-limit pick.

[github-actions]

Blocking issues found — see review comments.

Requires review. Bugs fixed

[github-actions]

No blocking issues found.

[github-actions]

No blocking issues found.