Split connector extra settings per credential path

Registration.ExtraSettings was a single flat list, but the API-key and
client-credentials connect dialogs need different fields whenever a
provider offers both paths, because a different create resolver and a
different driver sits behind each. Replace it with
APIKeyExtraSettings and ClientCredentialsExtraSettings, and split the
GraphQL surface to match so a client cannot render one path's settings
on the other.

This fixes two connectors that could not be connected at all.

1Password declared accountId and region only, which are the
client-credentials shape. The API-key dialog therefore rendered those
two fields, mapAPIKeyExtraSettingToField returned nil for both so
buildExtraFields discarded them, and the SCIM-bridge driver failed on an
empty SCIMBridgeURL. The console already mapped scimBridgeUrl, but no
registration declared that key, so the branch was dead. It now declares
scimBridgeUrl on the API-key path and accountId + region on client
credentials.

Langfuse declared baseUrl as required, but mapAPIKeyExtraSettingToField
had no LANGFUSE case, so buildExtraFields dropped the value the customer
typed and the mutation failed with "langfuseBaseUrl is required". Every
other extra-settings provider had a case. The GraphQL input field, the
settings struct, the probe builder and the driver were all already
correct; only the console mapping was missing.

buildExtraFields now takes the settings list explicitly instead of
reading it off the provider, so each dialog passes its own path's list
and cannot silently iterate the other one.

Register rejects a settings list for a path the provider does not offer,
and an empty or duplicate setting key within one list. A key repeated
across the two lists is allowed: that is how a dual-path provider
declares a setting both dialogs need.

The new resolver tests walk the whole chain the console walks, from the
key a Registration declares through the mutation input field to the
persisted settings struct, so a key renamed on one side and not the
other fails in CI instead of at connect time.

Signed-off-by: Aurélien Sibiril <81782+aureliensibiril@users.noreply.github.com>

pkg/connector/provider/one_password_test.go

@@ -34,11 +34,43 @@ import (
 	"go.probo.inc/probo/pkg/coredata"
 )
 
+// TestOnePasswordRegistrationMetadata pins the per-connect-path settings
+// split. 1Password is the only registration offering both paths, and each
+// needs different settings because a different driver sits behind each: a
+// dialog handed the other path's list would collect fields the create
+// resolver rejects, which is exactly how the API-key path was broken while
+// the two shapes shared one flat list.
+func TestOnePasswordRegistrationMetadata(t *testing.T) {
+	t.Parallel()
+
+	r := provider.NewBuiltinRegistry()
+	reg, ok := r.Get(coredata.ConnectorProviderOnePassword)
+	require.True(t, ok, "1Password provider must be registered")
+
+	assert.Equal(t, "1Password", reg.DisplayName)
+	assert.True(t, reg.SupportsAPIKey)
+	assert.True(t, reg.SupportsClientCredentials)
+
+	require.Len(t, reg.APIKeyExtraSettings, 1)
+	assert.Equal(t, "scimBridgeUrl", reg.APIKeyExtraSettings[0].Key)
+	assert.Equal(t, "SCIM Bridge URL", reg.APIKeyExtraSettings[0].Label)
+	assert.True(t, reg.APIKeyExtraSettings[0].Required)
+
+	require.Len(t, reg.ClientCredentialsExtraSettings, 2)
+	assert.Equal(t, "accountId", reg.ClientCredentialsExtraSettings[0].Key)
+	assert.Equal(t, "Account ID", reg.ClientCredentialsExtraSettings[0].Label)
+	assert.True(t, reg.ClientCredentialsExtraSettings[0].Required)
+	assert.Equal(t, "region", reg.ClientCredentialsExtraSettings[1].Key)
+	assert.Equal(t, "Region", reg.ClientCredentialsExtraSettings[1].Label)
+	assert.True(t, reg.ClientCredentialsExtraSettings[1].Required)
+}
+
 // TestOnePassword_NewDriver_DispatchByGrantType is the pre-merge gate
 // for the 1Password closure. The OnePassword registration dispatches
-// between two drivers based on the connector's OAuth2 grant type —
-// this test asserts both paths construct without error from a
-// coredata.Connector shaped for each grant type.
+// between two drivers on GrantType(), which is "" for an API-key
+// connection — this test asserts every connection shape reaching the
+// closure constructs the driver whose settings the matching
+// per-path settings list collects.
 func TestOnePassword_NewDriver_DispatchByGrantType(t *testing.T) {
 	t.Parallel()
 
@@ -69,6 +101,28 @@ func TestOnePassword_NewDriver_DispatchByGrantType(t *testing.T) {
 		assert.IsType(t, &drivers.OnePasswordUsersAPIDriver{}, drv)
 	})
 
+	// The production API-key path: an *APIKeyConnection makes GrantType()
+	// return "", so it falls through to the SCIM-bridge driver and reads the
+	// SCIMBridgeURL that APIKeyExtraSettings collects.
+	t.Run("api key uses SCIM-bridge driver", func(t *testing.T) {
+		t.Parallel()
+
+		raw, err := json.Marshal(&coredata.OnePasswordConnectorSettings{
+			SCIMBridgeURL: "https://scim.example.test",
+		})
+		require.NoError(t, err)
+
+		conn := &coredata.Connector{
+			Provider:    coredata.ConnectorProviderOnePassword,
+			RawSettings: raw,
+			Connection:  &connector.APIKeyConnection{APIKey: "scim-token"},
+		}
+
+		drv, err := reg.NewDriver(context.Background(), httpclient.DefaultClient(httpclient.WithSSRFProtection()), conn, nil)
+		require.NoError(t, err)
+		assert.IsType(t, &drivers.OnePasswordDriver{}, drv)
+	})
+
 	t.Run("authorization_code uses SCIM-bridge driver", func(t *testing.T) {
 		t.Parallel()