fix(review): load GitCode PR files as one bounded response

[guantw]

Summary

GitCode returns GET /pulls/{number}/files as a single response that is truncated at 3,000 entries, with no usable pagination and no total-count header (see the GITCODE_PULL_REQUEST_FILES_RESPONSE_LIMIT contract). The previous code split this endpoint into per-page GitHub-style requests that never paginated effectively, silently losing files on larger PRs.

Changes

• gitcode_review_target_parts / gitcode_review_file_parts: replace the per-page bounded fetch with a single bounded request (4 MB), keep the 1,000-item review-target cap, and apply file-derived change stats to the pull request.
• Detail page Files section: switch from server-side page parameters to client-side slicing (gitcode_files_pagination + slice_page), and stop claiming an exact total when the response is at the truncation limit.
• gitcode_file_from_value: prefer old_path, infer status from new_file / deleted_file / renamed_file flags, and parse a nested patch.diff payload.
• Oversized GitCode files responses now surface an explicit Api error instead of a generic parse failure.
• Added unit tests for the new mapping, truncation-aware pagination, and error reporting.

Notes

• file_page_hint is retained in the trait surface but is no longer used by the GitCode path.
• Verified targets are GitCode-only; GitHub and GitLab flows are unchanged.