Define API Development Strategy and Scope for Synapse SDK

We need to establish clear principles and guidelines for API development in the Synapse SDK to ensure consistent decision-making as feature requests arise. This discussion will help us determine what functionality belongs in the core SDK versus external services like subgraphs, indexers, etc.

## Done Criteria
- Written API development strategy document outlining scope and principles
- Guidelines for when to implement features in SDK vs. delegate to external services
- Consensus among core team on API boundaries and responsibilities

## Why Important
- Consistent Decision Making: Provides clear criteria for evaluating feature requests like #50
- Focused Development: Prevents scope creep and keeps the SDK focused on core functionality
- Resource Allocation: Helps prioritize development efforts on essential features vs. nice-to-have additions
- Architecture Clarity: Establishes clear boundaries between SDK responsibilities and ecosystem services

## Opening Questions for starting discussion
- What constitutes "core" vs "auxiliary" functionality for the SDK?
- When should features be implemented via subgraphs/indexing vs. direct SDK methods?
- How do we balance developer convenience with SDK simplicity?
- What are the performance and maintenance implications of different approaches?
- How do we handle features that could be implemented multiple ways (on-chain queries, APIs, local caching)?

## Notes
This discussion was prompted by issue #50 that require decisions about SDK scope and responsibilities.

No file or test entry point is named. Start by reviewing issue #50 and the opening questions about core SDK functionality, subgraphs, indexers, APIs, on-chain queries, and caching. Done means producing the strategy document, defining SDK-versus-service guidelines, and reaching consensus among the core team on API boundaries.

Written by the indexing model from the issue text.