Lightweight provider tier + accretive connector growth for `@repo/app-providers`

[jeevanpillay]

Description

Add a lightweight provider tier to @repo/app-providers that supports proxy-only API providers alongside the existing full-featured providers (webhook + backfill + events). One format covers both Lightfast-curated connectors (PlanetScale, Pinecone, Clerk, Stripe API) and user-defined custom APIs. The user adds an API key once and the provider becomes callable through the proxy.

Additionally, introduce accretive connector detection — using signals already flowing through the system (env var names in PR bodies, dependency files in connected repos, Sentry platform strings) to detect what services a team uses and suggest connectors.

Motivation

The current provider system requires significant engineering cost per provider (~8 files, compile-time registration in PROVIDERS, providerSlugSchema, PROVIDER_DISPLAY, env var config, OAuth flow support). This is justified for providers that need real-time webhooks, backfill, and event pipeline integration — but overkill for proxy-only API access.

Many useful providers (PlanetScale, Pinecone, Clerk, Upstash, OpenAI, SendGrid) only need: baseUrl + endpoints + API key → callable through the proxy. Users also need the ability to add their own arbitrary REST APIs.

Proposed Solution

Two-tier model

Tier 1: Full providers (existing) — GitHub, Linear, Sentry, Vercel, Apollo. Compile-time PROVIDERS registry. Webhooks, backfill, events, transformers.

Tier 2: Lightweight providers (new) — Minimal definition:

interface LightweightProvider {
  slug: string;
  displayName: string;
  description: string;
  baseUrl: string;
  authHeaderFormat: string;       // e.g., "Bearer {token}", "Api-Key {token}"
  defaultHeaders?: Record<string, string>;
  endpoints: Record<string, {
    method: "GET" | "POST" | "PUT" | "PATCH" | "DELETE";
    path: string;
    description: string;
    timeout?: number;
  }>;
}

Shared infrastructure (token vault, proxy executor, encryption) is already provider-agnostic — Apollo proves this pattern works today. Lightweight providers bypass the compile-time type lattice (providerSlugSchema, EVENT_REGISTRY, wire contract schemas) since they never flow through webhook/backfill paths.

Accretive detection

• Populate the existing (but empty) "service" entity category with env var prefix → service name mappings (e.g., PLANETSCALE_* → PlanetScale)
• Use get-file-contents GitHub proxy endpoint to scan package.json from connected repos for known SDK packages
• Surface suggestions: "We detected PlanetScale in your stack. Connect it?"
• Growth loop: popular user-defined providers get promoted to curated catalog

Open design questions

1. Where should Tier 2 definitions live? (DB table vs. code catalog vs. hybrid)
2. How should the provider column evolve? (Relax SourceType, prefix convention, or separate column)
3. Tier 2 → Tier 1 graduation path without breaking existing installations
4. Detection cadence (backfill-time, cron, or on-demand)