[Feature]: Build connector repository graph UI

[m43i]

Problem Statement

The backend/API now supports connector-backed repository graph creation and synchronization, but the connector UI was removed from PR #452 so that PR can stay focused on backend and API work. Users need a frontend flow to configure available connectors, install/connect providers, select repositories and branches, create repository graphs, inspect binding status, and trigger manual syncs.

Proposed Solution

Build frontend screens and interactions for the connector repository graph workflow using the existing typed helpers in apps/frontend/lib/api/connectors.ts:

• fetchConnectors(client) for listing active connector definitions from GET /connectors.
• startGitHubConnectorManifest(client, input) and completeGitHubConnectorManifest(client, input) for system-admin GitHub app setup via POST /connectors/github/manifest/start and GET /connectors/github/manifest/callback.
• createGitLabConnector(client, input) for system-admin GitLab connector setup via POST /connectors/gitlab.
• startConnectorConnect(client, connectorId, input) for starting an owner-scoped provider installation via GET /connectors/:id/connect.
• completeGitHubConnectorInstallation(client, input) for the GitHub installation callback via GET /connectors/github/install/callback.
• fetchConnectorInstallations(client, connectorId) for visible installations from GET /connectors/:id/installations.
• fetchConnectorRepositories(client, connectorId, installationId) for provider repositories from GET /connectors/:id/repositories?installationId=....
• fetchConnectorBranches(client, connectorId, installationId, repositoryId) for branches from GET /connectors/:id/repositories/:repositoryId/branches?installationId=....
• createRepositoryGraph(client, connectorId, input) for creating a code graph binding via POST /connectors/:id/repository-graphs.
• fetchRepositoryGraphBinding(client, bindingId) for binding status from GET /repository-graph-bindings/:id.
• syncRepositoryGraphBinding(client, bindingId) for manual sync via POST /repository-graph-bindings/:id/sync.

The graph files experience should probably become a tabbed entry point for adding sources:

• Uploads: existing file/archive upload flow.
• URLs: repository URL ingestion via POST /graphs/:id/urls.
• Connector: connector-backed repository selection and sync. Show this tab only when at least one usable connector is configured for the current user/owner context.

The UI should support at least these user journeys:

• System admins can create/manage connector definitions, including GitHub manifest setup and GitLab connector setup.
• Users with organization graph creation access can connect a provider at organization scope, browse accessible installations/repositories/branches, and create organization-owned repository graphs.
• Users with team graph creation access can connect a provider for a team, browse matching team installations/repositories/branches, and create team-owned repository graphs.
• Users who can view a graph can see repository binding details and sync status.
• Users who can manage the graph owner can trigger manual repository sync when the binding has webhooks enabled.
• Provider webhooks are not directly user-facing, but UI status should reflect pending, syncing, synced, and failed binding states plus syncErrorCode.

Backend/API functionality available for the UI:

• Connector definitions and provider installation flow.
• Repository and branch discovery for a selected installation.
• Repository graph creation with organization/team ownership.
• Repository graph binding lookup and manual sync.
• Webhook-driven sync for GitHub/GitLab pushes.
• Public repository URL ingestion through POST /graphs/:id/urls remains available for graph file management flows.

Alternatives Considered

Keep connector UI in PR #452. That made the PR too broad, so the UI is intentionally split into this follow-up while retaining typed API helpers to reduce duplicate frontend wiring later.

Additional Context

PR #452 contains the backend/API implementation and the helper functions listed above. The removed UI files can be referenced from the branch history if useful, but the implementation should be reviewed as frontend work separately from the backend/API PR.

[m43i]

Will be done differently later