Add repository-wide commit search across branches

### 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.

Start by reading the existing search_commits and list_commits tool implementations and their GitHub API calls. Check whether the API supports repository-wide commit discovery with author and date filters, then identify the appropriate tool design and tests. Done means matching commits are returned across non-default branches with pagination and useful SHA or ref metadata.

Written by the indexing model from the issue text.