feat: add multi analytics database routing for SQL and introspection

[mjalalimanesh]

Summary

This PR adds optional analytics database routing for SQL and schema introspection while preserving original behavior when no analytics env vars are configured.

What changed

• Added db/config.py with:
  • get_internal_db_url()
  • get_analytics_registry()
  • get_analytics_descriptions()
  • has_explicit_analytics_dbs()
• Added routed analytics SQL tools in dash/tools/sql.py.
• Updated dash/tools/introspect.py to use the same routing model.
• Updated dash/agents.py wiring:
  • internal DB remains for knowledge/learnings/AgentOS
  • SQL and introspection tools use analytics registry
  • AVAILABLE DATABASES section is shown only when explicit analytics DBs are configured
• Added optional database metadata handling in semantic/business context and bundled F1 metadata JSON.
• Updated dash/scripts/load_data.py routing behavior:
  • single DB: routes to sole DB
  • multi DB: requires valid --database
• Minimal docs updates in README.md, compose.yaml, and example.env.

Behavior and compatibility

• Backward compatible default path:

  • If no ANALYTICS_DB_* vars are set, Dash behaves as single-DB mode and uses internal DB_* DB as analytics source.

• Multi-DB mode:

  • database is required for SQL/introspection tool calls.

• DB_* variables are for Dash’s internal database only (knowledge, learnings, and AgentOS state).
  Analytics query targets are configured separately with ANALYTICS_DB_=<sqlalchemy_url> and optional ANALYTICS_DB__DESC=.

  Examples:

  • ANALYTICS_DB_MAIN=postgresql+psycopg://user:pass@host:5432/f1
  • ANALYTICS_DB_SALES=postgresql+psycopg://user:pass@host:5432/sales
  • ANALYTICS_DB_MAIN_DESC=F1 historical dataset

  Behavior:

  • If no ANALYTICS_DB_* variables are set, Dash stays backward-compatible and uses the internal DB_* database as a single analytics source.
  • If multiple analytics DBs are configured, tool calls should pass the database argument with the logical name (e.g., main, sales).

Security model

• No app-layer SQL write guard.
• Read-only safety is expected to be enforced by analytics DB credentials/permissions.