Pluggable source control providers (custom CLI-backed providers for unsupported hosts)

[vanilla-wave]

Problem

Both the VCS layer (VcsDriverKind: git, jj) and the source control provider layer (SourceControlProviderKind: github, gitlab, forgejo, azure-devops, bitbucket) are closed enums. The provider is picked from a hardcoded hostname match on the remote URL. A repository hosted on anything else, such as an internal or less common code review system, is classified as unknown, and the change request features (create, list, status, checkout) don't work for it.

Today the only way to get support is to add it to core or keep a fork. A fork is painful because the enums sit in packages/contracts and are shared by the server and the client, so almost every nightly conflicts with it.

Proposal

Add a minimal extension point for source control providers (and, possibly later, VCS drivers) that doesn't require changes to core. For example:

• User-level config that maps a remote host pattern to a custom provider
• The custom provider is a CLI or script with a small, documented contract, e.g. JSON in and JSON out for create, list, view, status, and checkout, much like the built-in providers already wrap gh, glab, and az
• Graceful degradation: operations the provider doesn't implement stay hidden, as they are for unknown today

This is a narrower, concrete slice of the general extension system discussed in #6714, and it relates to the VCS pluggability question raised in #7033.

Why

It lets people use T3 Code with hosting and review systems that will never get first-class support, without forking and without adding maintenance cost to core.