Add repository-wide commit search across branches

先閱讀現有的 search_commits 和 list_commits 工具實作及其 GitHub API 呼叫。檢查 API 是否支援使用作者和日期篩選條件在整個儲存庫中尋找提交，然後找出適當的工具設計與測試。完成的標準是：能夠跨非預設分支傳回相符的提交，並提供分頁以及有用的 SHA 或 ref 中繼資料。

Describe the feature or problem you’d like to solve

The current search_commits tool searches commit messages on the repository's default branch only. This makes it difficult to reliably discover work performed by a developer on feature, bugfix, or other non-default branches that have not yet been merged.

For example, a developer may make several commits on feature/worklog-ai during the day while the repository's default branch is development. Those commits will not be returned by search_commits until they are merged into the default branch.

Using list_commits does allow specifying a branch through the sha parameter, but discovering a user's activity across an entire repository would then require listing branches and querying commits for each branch individually. This becomes inefficient for repositories with a large number of branches and also creates significant duplication because branches frequently share commit history.

A repository-wide way to find commits by author and date, independent of the branch on which they currently exist, would make the MCP server much more useful for developer activity, worklog, analytics, and code-agent workflows.

Proposed solution

Add a tool or extend an existing tool to support repository-wide commit discovery across branches.

For example:

search_repository_commits

Parameters could include:

• owner — Repository owner
• repo — Repository name
• author — GitHub username or email
• since — Start of the time range in ISO 8601 format
• until — End of the time range in ISO 8601 format
• page — Pagination page
• perPage — Results per page

The tool should return commits belonging to the specified repository and matching the author/date filters regardless of whether the commits are currently reachable from the default branch.

Ideally, results should include the commit SHA and enough metadata to identify the relevant branch/ref when possible.

The implementation should avoid requiring clients to enumerate every repository branch and call list_commits separately for each branch.

An alternative would be to extend search_commits with an explicit repository-wide/non-default-branch mode if that fits the existing tool design better.

Example prompts or workflows (for tools/toolsets only)

1. "Show me everything I committed to owner/repository today, including commits on feature branches that haven't been merged yet."

2. "Find all commits by username in owner/repository between August 31 and September 1, regardless of which branch they were made on."

3. "Generate a daily worklog for username based on all commits made in this repository today, including unmerged feature branches."

4. "Find all work performed by username in this repository during the last 7 days, including commits that are not present on the default branch."

5. "List the commits made by username in this repository today and group them by branch or related work."

Additional context

This is particularly useful for developer productivity and worklog workflows.

A common development workflow is for developers to work on feature or bugfix branches and merge them into main/development later. A daily activity query should not require those commits to already be merged.

The current search_commits behavior is documented as searching commit messages on the default branch only. list_commits can target a specific branch using sha, but using it to discover all user activity requires enumerating branches, which does not scale well for repositories with many branches.

The desired behavior is therefore a repository-level activity query that can efficiently identify commits by author and time range without requiring clients to know the relevant branches beforehand.