Fix maintainers editing when they own a fork

What does this MR do and why?

This fixes the bug where maintainers with forks were incorrectly being routed to their fork projects instead of the upstream project when editing files.

Changes Made

File: app/helpers/blob_helper.rb

1. Updated edit_blob_target_project_id method

def edit_blob_target_project_id(project, ref, can_push_to_branch)
  # If user has direct push access to the project, always use upstream
  return project.id if can?(current_user, :push_code, project)
  
  # If user can push to this specific branch, use upstream
  return project.id if can_push_to_branch
  
  # Otherwise, try to use fork
  edit_blob_fork_project_id(project, ref) || project.id
end

2. Updated edit_blob_target_project_path method

def edit_blob_target_project_path(project, can_push_to_branch)
  # If user has direct push access to the project, always use upstream
  return project.full_path if can?(current_user, :push_code, project)
  
  # If user can push to this specific branch, use upstream
  return project.full_path if can_push_to_branch
  
  # Otherwise, try to use fork
  edit_blob_fork_project_path(project) || project.full_path
end

3. Added edit_blob_next_fork_branch_name method

def edit_blob_next_fork_branch_name(project, ref, can_push_to_branch)
  # Only generate fork branch name if we're actually going to use the fork
  return if can?(current_user, :push_code, project)
  return if can_push_to_branch
  edit_blob_fork_project(project)&.repository&.next_branch('patch')
end

4. Updated edit_blob_app_data method

• Conditionally includes next_fork_branch_name only when fork will be used
• Prevents the key from being added to the hash when user has upstream access

What the Fix Does

Before:

• Maintainer with fork + protected branch → Routed to fork ❌
• API calls went to fork project causing 500 or "file doesn't exist" errors ❌

After:

• Maintainer with fork + protected branch → Routed to upstream ✅
• API calls go to upstream project with correct permissions ✅
• Commits create new branches in upstream, not fork ✅

Edge Cases Handled

User Type	Has Fork	:push_code	can_push_to_branch	Result
Maintainer	Yes	✅	✅	Upstream ✅
Maintainer	Yes	✅	❌	Upstream ✅ (Fixed!)
Developer	Yes	❌	✅	Upstream ✅
External	Yes	❌	❌	Fork ✅

References

• #590944 (comment 3106333247)+

Screenshots or screen recordings

Before	After
branch: "patch-1" commit_message: "Edit ADOPTERS.md" content: "ON MASTER\n\nTwitter isn't the only company using Flight..." file_path: "ADOPTERS.md" id: "23" last_commit_id: "02d8ce025e459006b4fd778c368ce7dc10987316" start_branch: "master"	branch: "root-master-patch-97036" commit_message: "Edit ADOPTERS.md" content: "ON FIX BRANCH\n\nTwitter isn't the only company using Flight..." file_path: "ADOPTERS.md" id: "7" last_commit_id: "02d8ce025e459006b4fd778c368ce7dc10987316" start_branch: "master"

How to set up and validate locally

1. Go to a project, in which your user is a maintainer
2. Fork the project
3. Go to Branch rules for your default branch, for example http://127.0.0.1:3000/flightjs/Flight/-/settings/repository/branch_rules?branch=master
4. Set Allowed to push and merge to No one
5. Open a file in this project and edit it with Single file editor
6. Make sure your able to submit the changes to that project.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #590944 (closed)