Split provider API documentation

[luisleo526]

Summary

• turn docs/providers.md into a top-level provider catalog and shared lifecycle guide
• add second-level API guides for CCXT, CSV, SQLite, and SQLAlchemy
• add a shared tabular schema-mapping guide used by file and database providers
• route README, getting-started, backtesting, and documentation-home links through the provider catalog
• require future provider contributions to add docs/providers/<provider>.md
• make documentation link validation recurse through nested guide directories

Why

The previous provider page mixed registry concepts, the complete CCXT API, and three local/database APIs at one level. It was difficult to scan and would become less maintainable with every provider contribution. The new hierarchy gives each provider an independent API surface while keeping shared concepts discoverable from one catalog.

Documentation structure

• docs/providers.md — catalog, shared lifecycle, common requests and errors
• docs/providers/ccxt.md — CCXT catalog, bars, trades, configuration, errors
• docs/providers/csv.md — CSV constructor, mapping, harness configuration, limitations
• docs/providers/sqlite.md — read-only SQLite reflection/query API
• docs/providers/sqlalchemy.md — SQLAlchemy reflection, URL and engine configuration
• docs/providers/tabular-schema.md — shared schema discovery and normalization contract

Validation

• ruff format --check src tests
• ruff check .
• mypy src
• pytest — 86 passed, 2 expected Docker-gated skips
• python -m build
• recursive relative-link validation for README, CONTRIBUTING, and all nested Markdown guides