push_files takes ~70s per call (both success and fast-fail cases)

先追蹤進入點 push_files 及其 GitHub Git Trees 與 commit 操作。在授權失敗路徑和成功路徑中分別重現包含七個檔案的 payload，並比較約 70 秒的延遲發生在哪裡。完成的標準是已找出並處理延遲原因，或已明確診斷該原因，並為受影響的路徑提供涵蓋。

Describe the bug

push_files calls are consistently slow (~1m12s–1m13s) in our MCP flow, even when one call fails with authorization error and the next call succeeds with the same payload.

This suggests significant latency before/around final Git operations, not only at final commit update step.

Affected version

Using hosted/remote GitHub MCP server, version: github-mcp-server/remote-57ddf9ca0de2f61fc022ca3cff21efc81a65fc99 (observed on 2026-03-08 via initialize -> serverInfo.version)

Steps to reproduce the behavior

1. Call github.push_files with a payload of 7 files (Twig templates + one larger classes/Email.php) to:
   • repo: https://github.com/Sogl/grav-plugin-login
   • branch: https://github.com/Sogl/grav-plugin-login/tree/feature/multipart-emails
2. First call result:
   • Error: failed to create tree: POST https://api.github.com/repos/Sogl/grav-plugin-login/git/trees: 403 Resource not accessible by personal access token []
   • Client timing: Worked for 1m 12s
3. Fix PAT permissions and call github.push_files again with the same payload.
4. Second call result:
   • Success, ref updated to commit: https://github.com/Sogl/grav-plugin-login/commit/8be0cd10415515109476025379545999f52b87b0
   • Client timing: Worked for 1m 13s

Expected vs actual behavior

Expected:

• Latency in seconds for this payload size, or at least clear diagnostics if server-side queueing/throttling is involved.

Actual:

• Both failed and successful calls take ~70+ seconds with almost identical duration.

Logs

First call (failed, ~1m12s):

• failed to create tree: POST https://api.github.com/repos/Sogl/grav-plugin-login/git/trees: 403 Resource not accessible by personal access token []

Second call (success, ~1m13s):

• {"ref":"refs/heads/feature/multipart-emails", ... "sha":"8be0cd10415515109476025379545999f52b87b0"}

Request payload was the same large push_files body in both calls (7 files, full file contents).