[Story]: Link existing sources to additional projects without re-ingesting

[adoLime]

User Story

As an Admin or PM, I want to connect an already-connected source (GitHub repository, Jira import, or any future source type) to any additional project without re-fetching or re-importing its content, so that the source is reused across projects and the system does not waste API calls, ingestion time, or storage on duplicates.

This applies across PMs: if PM-A has already connected a source to project A, and PM-B (a different PM, managing project B) connects the same source to project B, the system should reuse the existing connection and artifacts transparently without either PM knowing about the other's project.

Context & Motivation

• Type: Functional (Backend, deduplication, source-agnostic + Cross-PM)
• Parent epic: 03 EPIC - Connectors & Artifact Ingestion #52 (03 EPIC – Connectors & Artifact Ingestion)
• Teams: team:backend (lead), team:frontend (PM feedback UI), team:ai (vector index coordination?)
• Related: [Story]: GitHub repository connector v0 (commits, files, issues, PR metadata) #159 (GitHub connect endpoint), [Story]: Jira CSV issue connector adapter #160 (Jira CSV connector), [Story]: Create project + connect data sources in one flow #256 (project wizard), [Story]: GitHub org/user discovery & multi-repo ingestion selection #244 (discovery + bulk connect)

Critical PM-scoping constraint: A PM only sees and manages their own projects. They have no way to know whether a source is already ingested in another PM's project and they must not be able to infer it from the response beyond the fact that reuse happened. Therefore:

• Reuse must happen server-side, automatically, transparently.
• The PM must receive UI feedback that reuse happened (so the missing ingestion jobs don't look like a bug), but without revealing which other project(s) the source is linked to.

Acceptance Criteria

Source-agnostic (apply to every connector)

• When a source that already has artifacts in the store is linked to any additional project, the existing artifacts are backfilled with the new projectId so the source is immediately usable in the new project's chat/RAG without re-ingestion.
• The backfill is idempotent: linking the same project twice does not duplicate projectId entries on artifacts.
• Cross-PM reuse: the reuse logic works when two different PMs (each managing their own project) connect the same source: PM-A connecting to project A, then PM-B connecting the same source to project B reuses the existing connection and artifacts.
• Project-scoped access check runs before linking. A PM cannot link a source to a project they do not manage (403).
• The reuse/backfill pattern is documented once (e.g. in a short ADR) so future connectors implement it by convention, not by accident.

Privacy / Project-scoping

• The API response for a reuse/link operation does not reveal which other project(s) the source is already linked to (no project IDs, no project names, no PM identities from other projects).
• The only signal returned is a boolean/flag indicating that reuse happened, so the frontend can show appropriate feedback without leaking cross-project information.
• Error messages (e.g. PAT-related failures) are worded so they do not allow inferring the existence or identity of other projects.

PM feedback (Frontend)

• When a connect/import triggers reuse (no new ingestion started), the UI shows a clear, non-alarming feedback to the PM e.g.:"This source is already available in SprintStart and has been linked to your project. No re-ingestion needed."
• The feedback does not mention other projects, PMs, or which project the source was originally connected to.
• Loading/success/error states work consistently for both "new connection" and "reused connection" paths.
• i18n (en/de); works in light and dark themes.

GitHub-specific (concrete first implementation)

• When POST /api/v1/github/connect is called with owner + name that already has a GithubRepositoryConnection, the existing connection is reused: only the new projectId is appended to projectIdsInternal. No second connection row, no new snapshot, no new config, no full re-ingestion.
• When the connection does not exist yet, the current full-connect flow runs unchanged.
• Response includes a wasReused flag (or equivalent) so the frontend can distinguish new-connect vs. reuse.
• Unit tests cover: reuse-existing path, idempotent re-link, 403 for unauthorized PM, unchanged new-connection path, Cross-PM reuse (two different PMs, two different projects, same source).

Jira (#160 )

• Re-importing the same Jira artifacts for a different project does not create duplicate artifacts; existing artifacts are backfilled with the new projectId.

Open Design Question (to be decided by the implementing team)

PAT ownership across PMs (Cross-PM reuse):

Today each GithubRepositoryConnection is bound to a single GithubUser (PAT owner) via @ManyToOne. When PM-B connects a repo that PM-A already connected with PM-A's PAT, the system must decide which PAT continues to be used for future syncs. Options:

• (a) Reuse PM-A's PAT (existing connection unchanged). Simplest MVP. Risk: if PM-A leaves the org or revokes their PAT, the connection breaks for all linked projects, including PM-B's.
• (b) Introduce a system-wide / org-wide PAT. It requires a new concept and admin-managed PAT storage.
• (c) Make the connection PAT-agnostic. Allow multiple PATs per connection with fallback on revocation. It needs a fallback strategy when one PAT is revoked.