Dependency adapter isolation layer

[snowfox1003]

Problem

The 14 Django apps each independently implement API client setup for their respective external platforms — GitHub (5,000 requests/hour/token), Discord, Slack (tiered per-method limits), YouTube (quota units/day), and mailing lists. The project carries 13+ production dependencies with no adapter isolation, meaning a major version bump in the Pinecone SDK, Slack SDK, or GitHub API propagates directly into every collector that uses it. The cppa_pinecone_sync app is the most coupled integration path, and core/ serves as a shared utility module rather than a stable internal API — dependency-specific logic is scattered rather than centralized behind stable interfaces. The CHANGELOG notes that cross-app import edges have been resolved (Pinecone via cppa_pinecone_sync.sync_api, dashboard model shim removed, etc.), but SDK calls remain directly embedded in collector code. Without adapters, tests cannot mock external services without patching the real SDK at multiple call sites across multiple apps.

Acceptance Criteria

• Adapter interfaces defined for top 3 external dependencies (Pinecone, Slack SDK, GitHub API)
• At least one adapter implemented (e.g., PineconeAdapter wrapping the SDK)
• Existing collector code migrated to use the adapter
• Tests can mock the adapter without patching the real SDK
• Dependency version bumps isolated to the adapter module

Implementation Notes

• Pattern: thin wrapper classes in core/adapters/ implementing a stable interface
• Start with PineconeAdapter since cppa_pinecone_sync is the most coupled path
• The adapter should expose only the operations collectors actually use
• The Pydantic boundary schemas already added at ingestion (api_schemas.py per app) provide typed payloads — adapters would sit below that layer

References

• Related files: cppa_pinecone_sync/, core/, github_activity_tracker/, cppa_slack_tracker/