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

[bobleer]

Summary

Carries the change from GCWing#2463 (fix(review): load GitCode PR files as one bounded response) plus two review fixes found while reviewing it.

From the original commit: GitCode answers GET /pulls/{number}/files with a single response truncated at 3,000 entries, with no usable pagination and no total-count header (the GITCODE_PULL_REQUEST_FILES_RESPONSE_LIMIT contract). The previous code split that endpoint into per-page GitHub-style requests that never paginated, so it re-fetched the same payload for every page and, in the detail Files section, returned the whole list for every page instead of the requested slice.

Review fixes added on top:

• The review-target path replaced the provider change counts with sums over the first 1,000 mapped files. A pull request with more changed files than that budget then reported changed_files equal to the budget, which made review_target_from_parts compute omitted_file_count = 1 instead of the real number of dropped files. It now reuses apply_gitcode_pull_request_change_stats, the rule that already reads the whole files response, keeps the provider count when it is larger, and refuses to claim truncated totals.
• The single bounded request was sized with MAX_REVIEW_TARGET_RESPONSE_BYTES (4 MB), the pull request detail budget. send_json_response already allowed 16 MB, so file lists between 4 MB and 16 MB that used to load became a hard Api error. The GitCode files request now has its own budget sized against the documented 3,000-entry single response.

Fixes #

Type and Areas

Type: bug fix

Areas: Rust services (bitfun-services-integrations, review-platform provider)

Motivation / Impact

GitCode pull requests silently lost files on larger changes, and the detail Files section paged against parameters the provider ignores. After this change:

• Review targets and file diffs read the file list from one bounded response and keep the provider's own file count, additions, and deletions, so the omitted-file count and the provider_file_list_incomplete limitation describe what was really left out.
• The detail Files section slices client-side and stops claiming an exact total when the response sits at the truncation limit.
• gitcode_file_from_value prefers old_path, infers status from the new_file / deleted_file / renamed_file flags, and parses a nested patch.diff payload.
• An oversized files response surfaces an explicit Api error instead of a generic parse failure.

GitHub and GitLab flows are untouched. No persisted shape, DTO, Tauri command, or wire protocol changes, so nothing here affects upgrade compatibility or cross-version negotiation.

Verification

cargo test --locked -p bitfun-services-integrations --no-default-features --features review-platform --lib review_platform::tests::
# 85 passed; 0 failed

cargo check --locked -p bitfun-services-integrations --no-default-features --features review-platform --all-targets
# clean, no warnings

cargo fmt -p bitfun-services-integrations -- --check
# no diff in review_platform.rs

Remote scenarios: this is provider HTTP mapping inside a service crate, reached identically from desktop, CLI, mobile web, and dispatch targets. No host-specific API, no new blocking interaction, and no new desktop command, so the remote workspace policy table and the peer-device deny lists are unchanged.

Reviewer Notes

• file_page_hint stays in the trait surface for GitHub and GitLab; the GitCode path documents why it cannot use it.
• New coverage: nested patch.diff and flag-based status mapping, truncation-aware pagination that drops the exact total, the oversized-response error text, and a capped review target that still reports 1,500 omitted files out of a 2,500-file pull request.

Checklist

• This PR is focused and does not include secrets, temporary prompts, generated scratch files, or unrelated artifacts.
• Relevant verification is recorded above, or skipped checks are explained.
• User-facing strings, docs, and locales are updated where applicable.