Use GitHub-signed commits for repository file write tools

## Summary

Repository write tools such as `create_or_update_file` and `push_files` can create unsigned commits. In repositories that require verified commit signatures, the MCP-created pull request is then blocked with:

> Commits must have verified signatures.

## Reproduction

1. Use the MCP server against a repository with a ruleset/branch protection rule requiring signed commits.
2. Create a branch.
3. Use `create_or_update_file` or `push_files` to write a commit.
4. Open a pull request.

## Actual behavior

The commit can be reported by GitHub as `verification.verified=false` with `verification.reason=unsigned`, and the pull request cannot be merged while the signed-commit rule is active.

## Expected behavior

Repository write tools should use a GitHub API path that can produce GitHub-verified commits when supported by the authenticated actor, so MCP-generated pull requests can satisfy signed-commit requirements without clients managing GPG or SSH signing keys.

## Notes

I verified in an internal test repository that switching the file write to GraphQL `createCommitOnBranch` produced a commit with:

- `verification.verified=true`
- `verification.reason=valid`

The existing `delete_file` implementation already avoids the simpler REST contents deletion path because of commit signing behavior. The same issue can affect create/update and multi-file writes.

## Proposed fix

Use GraphQL `createCommitOnBranch` for `create_or_update_file` and `push_files`, keeping the existing tool inputs and response shape as much as possible.

Start with the implementations of create_or_update_file and push_files, then compare them with the existing delete_file path and its use of GitHub APIs. Investigate GraphQL createCommitOnBranch and preserve the existing tool inputs and response shape. Done means writes produce GitHub-verified commits when supported and pull requests satisfy signed-commit requirements.

Written by the indexing model from the issue text.