Default to NamespaceCommitEmail from UI

What does this MR do and why?

Related to #26710

This MR causes the backend to observe configured project or root group commit email when committing through the single file editor or WebIDE.

Screenshots or screen recordings

How to set up and validate locally

1. Create a commit via the single file editor and/or WebIDE
2. Ensure your user has at least 3 e-mail addresses attached https://docs.gitlab.com/ee/user/profile/#add-emails-to-your-user-profile
3. As the merge requests to introduce the GraphQL and frontend for configuring commit emails isn't complete yet, you will need to create some via the rails console:

User.find(1).emails.pluck(:id, :email) # find e-mail ids
Project.find(6).project_namespace_id # find a project namespace id (take the project id from the project page)
Users::NamespaceCommitEmail.new(user_id: 1, namespace_id: XXX, email_id: 70) # use a project_namespace_id
Users::NamespaceCommitEmail.new(user_id: 1, namespace_id: XXX, email_id: 70) # use a group_id (NOT for the group containing the project above)

4. Push a change for the project using the single file editor or WebIDE
5. Ensure the correct e-mail was used (easiest way to is to click the commits feed button from the commits page e.g. http://gdk.test:3000/gitlab-org/gitlab-shell/-/commits/main?feed_token=ts6MWxcgjV9aGy15_YAs&format=atom)
6. Push a change for a project in the group using the single file editor or WebIDE
7. Ensure the correct e-mail was used (easiest way to is to click the commits feed button from the commits page e.g. http://gdk.test:3000/gitlab-org/gitlab-shell/-/commits/main?feed_token=ts6MWxcgjV9aGy15_YAs&format=atom)

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.