feat(engine): expose structured commit metadata for pull request evaluation

[sachin9058]

Summary

This PR builds on the existing commit iteration support by introducing structured commit metadata extraction for pull request evaluation.

Previously, commit data was accessed directly from provider-specific objects within the evaluation flow. This change introduces a lightweight abstraction (CommitInfo) to normalize commonly used fields such as SHA, message (first line), and author.

The implementation:

• Adds a new commitinfo package to avoid import cycles and provide a reusable abstraction
• Introduces a CommitInfo struct for normalized commit metadata
• Adds a helper function to extract structured data from GitHub commit objects
• Updates commit logging to use structured metadata instead of raw commit fields

This change is intentionally scoped as a foundational improvement and does not introduce any commit-level policy enforcement.

Testing

• Verified commit metadata extraction across multiple commits
• Confirmed no changes to existing behavior
• Ran full test suite:
  go test ./...
• Ensured no import cycles or build issues after refactor

[sachin9058]

This follows up on the earlier commit iteration work and prepares the system for future commit-level policy checks.

[coveralls]

coverage: 59.416% (-0.1%) from 59.539% — sachin9058:feat/commit-metadata-extraction into mindersec:main

[sachin9058]

This test appears to be timing-sensitive. It passes consistently locally and may be flaky due to the short wait duration.

[evankanderson]

Question: do we have a high-level design for what's being built, and how it will be used?

Given that this probably requires exposing some number of functions to e.g. the Rego evaluator, it would be handy to follow this approach:

1. Update the issue with the shape of the proposed solution. This should look like:

   a. A problem statement (we aim to address the following types of rules...)

   b. Background that's helpful in understanding the problem

   c. An outline of the full solution (e.g. "with the following 3 primitives, we can cover all but one use case")

   1. This should include some detail on what capabilities will not be available, and why. Engineering is about tradeoffs, so it's fine to rule out functionality that might be too expensive -- for example, the functions might fail for branches with more than a certain number of commits of difference.
   2. Include at least one example of what usage will look like

   d. (optional) were any alternatives considered? If so, what made this solution preferred?

2. Once the proposed solution is accepted, break out the implementation into sub-tasks (e.g. using the "create sub-issue" button).

3. Try to line up PRs with sub issues; it doesn't need to be 1:1, but having a map of

[sachin9058]

@evankanderson Thanks for the suggestion I’ve added a proposed high-level design in #2176 outlining how the pieces fit together and example usage.

Happy to iterate on the design before proceeding further.