[Story]: Ingest GitHub organization-level metadata (org profile, members, teams)

[adoLime]

User Story

As an Admin or PM, I want connecting a GitHub organization to also ingest the organization-level metadata (org profile, members, and teams incl. team membership), so that the AI can reason about the org's structure and people during onboarding and chat and not only about individual repositories.

Context & Motivation

• Type: Functional (Connectors & Artifact Ingestion)
• Parent epic: 03 EPIC - Connectors & Artifact Ingestion #52 (03 EPIC – Connectors & Artifact Ingestion)
• Teams: team:backend (org/members/teams ingestion + canonical artifacts), team:ai (RAG/onboarding consumption), team:frontend (org-level source view + enable/disable + schedule)
• Builds on: [Story]: GitHub org/user discovery & multi-repo ingestion selection #244 / [Feature]: GitHub org/user discovery + multi-repo ingestion sprintstart-backend#150 (closed/in-review — GitHub org/user discovery + multi-repo ingestion; discovery lists repos under an org but ingests per-repo only, this story adds org-level metadata on top), [Story]: GitHub repository connector v0 (commits, files, issues, PR metadata) #159 (GitHub repository connector v0), [Story]: Canonical artifact schema and metadata normalization #161 (canonical artifact schema and metadata normalization).

In Scope

• Organization profile (name, description, blog, location, avatar URL, plan/type, verified flag)
• Organization members (login, name, role: admin/member)
• Teams (name, description, privacy, parent team, member count) and team membership (user → teams)

Clarification needed on:

• Organization-level GitHub Projects v2 (name clash with SprintStart "project"; separate story)
• Organization discussions
• Audit log / security insights
• Fine-grained permissions / SSO settings

Acceptance Criteria

• Connecting a GitHub organization (via the existing [Story]: GitHub org/user discovery & multi-repo ingestion selection #244 org discovery) also ingests the org profile, members, and teams (incl. team membership).
• Org-level resources are persisted as canonical Artifact rows with sourceSystem = GITHUB, sharing the same ingestion store/table as repo artifacts ([Story]: Canonical artifact schema and metadata normalization #161).
• New ArtifactType variants exist for org-level resources (e.g. ORGANIZATION, MEMBER, TEAM).
• Org-level artifacts are pushed to the AI via /api/v1/ingest/sync (sourceSystem = GITHUB) and are retrievable/citable in chat and usable as onboarding grounding evidence.
• Org-level sources can be enabled/disabled and scheduled for update (CRON), reusing the existing connector/source-gating machinery ([Story]: PM-managed functional project roles + connector/source gating #175/[Feature]: Connector/source gating #212).
• RBAC: restricted to PM/Admin (hasAnyRole('PM', 'ADMIN')); a PM may only ingest orgs whose repos they already manage.
• Empty/loading/error states (org not found, token invalid, rate-limited by GitHub); i18n (en/de).
• Tests for mapper/provider.

Sub-Tasks (by team)

• Backend — SprintStartProject/sprintstart-backend — new GitHub API calls (GET /orgs/{org}, GET /orgs/{org}/members, GET /orgs/{org}/teams + team members), GithubOrgArtifactMapper + GithubOrgArtifactProviderService, new ArtifactType variants, GithubOrgArtifactMetadata, org-level sourceId scheme, enable/disable + CRON schedule, RBAC + token-scope handling.
• AI — SprintStartProject/sprintstart-ai — verify org-level artifacts flow into RAG/onboarding.
• Frontend — SprintStartProject/Wiki — surface org-level sources in the Data Ingestion page + Connectors tab (org card, member/team artifacts in the artifact table, org-level enable/disable + schedule UI mirroring GithubRepositorySyncSettings).
• QA — tests for: org vs. user connect, member/team ingestion, org-level enable/disable + schedule, RBAC (non-PM/non-Admin 403), empty/error/rate-limited states.