Support SCM-specific user accounts for push identity resolution

**Background**
`gitAccount` was previously stored as a single value against the user.

It was not being used and was removed from the UI in #1507. However, #1604 later introduced a dependency on `gitAccount` when resolving push identities.

Because of the merge order, the current implementation from @coopernetes now relies on a value that can no longer be configured through the UI.

**Problem**
There is also a more fundamental issue with storing a single `gitAccount` against a user.

Some git-proxy installations have repositories across multiple SCM providers, and the same user may have a different username/account on each provider.

For example, a user could have one username in GitHub and another in GitLab.

A single user-level `gitAccount` therefore cannot reliably represent the user's SCM identity.

**Proposed solution**

* Replace the single `gitAccount` value with SCM-specific account data stored against the user.
* Update the UI to view and populate these SCM accounts.
* Expose identity resolution through a generic, extensible provider interface so additional SCM providers can support their own account mapping. Update the providers under `src/service/gitProviders`, introduced in #1507, so that provider-specific knowledge for resolving push identities lives within the relevant provider.
* Update `checkUserPushPermission` to use the new SCM-specific account structure.

Start by tracing gitAccount usage and checkUserPushPermission, then inspect the providers under src/service/gitProviders and the existing user-account UI. Map how push identities are resolved for each SCM provider and how account data is stored. Done means users can configure provider-specific accounts, providers expose the mapping through an extensible interface, and permission checks use those accounts.

Written by the indexing model from the issue text.