Update and clarify signed commits behavior

What does this MR do?

Addresses the following user feedback:

Currently, the documentation doesn't explicitly state how the requirement for signed commits works for merge requests:

• What if the author of the MR doesn't have a GPG signature? Does it only matter that the developer merging the MR has a signature?
• Does it matter that the commits were created through the web interface (single-file editor or Web IDE)?
• What if there are more than one commit and from different authors (without signatures)?
• Does it matter whether the commits are squashed?
• Does it matter if the MR author uses community forks?
• How does applying Code Suggestions (by a MR author from a developer or vice versa) affect this?
• Any other conditions ...

Improves the documentation for signed commit requirements by adding clearer explanations of how the feature works in different scenarios. The main changes include:

• Better explanations of push rule behavior: The documentation now clearly explains that the "Reject unsigned commits" rule works differently depending on how code is merged. For example, when using "squash and merge," GitLab creates a new signed commit even if the original commits weren't signed, which allows the merge to succeed.
• Clearer merge strategy explanations: The documentation now breaks down exactly what happens with different merge approaches (fast-forward, merge commit, squash and merge) and how each one handles commit signing requirements.
• Community contribution guidance: Added information about how contributors from forks can work with signing requirements, including recommendations to use squash merging when contributors can't sign their commits.

Overall, these changes make the documentation much more practical and help users understand why they might see unexpected behavior with their signing requirements.

Review app

• Preview link: Enforce signed commits with push rules

Related issues

• Docs: Clarify the requirement for signed commit... (#577197)

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.