Implement internal time-series data model

[BytecodeBrewer]

Goal

Implement a small internal data model for historical exchange-rate and market time-series data.

Why

ARGUS uses multiple data sources such as the existing ExchangeRate API client, yfinance and possibly Frankfurter later. These sources return different response formats.

The analytics, dashboard, reporting, forecasting and future storage layers should not depend directly on external API response structures.

The storage research in docs/research-databases-and-storage.md already recommends a normalized model direction based on:

data_sources
instruments
price_bars

This ticket should turn that research into the first practical internal model that later storage and analytics code can use.

Implementation plan

1. Define a small internal model for market time-series data.
2. Support both FX rates and broader market data.
3. Keep the model OHLCV-ready, but allow fields such as open, high, low, adjusted_close and volume to be optional.
4. Represent FX rates from simple rate sources as close values.
5. Add helper conversion logic for pandas-friendly output if useful.
6. Add tests for the model and normalization behavior.
7. Document the model briefly in docs/ or near the implementation.

Scope

• Add internal model types for:
  • data source metadata
  • instruments
  • price bars / time-series rows
• Define required fields for the first implementation:
  • source name or source identifier
  • instrument symbol
  • asset class
  • timestamp / date
  • timeframe
  • close value
• Define optional OHLCV-ready fields:
  • open
  • high
  • low
  • adjusted_close
  • volume
  • currency
  • exchange
  • base_currency
  • quote_currency
• Add basic validation where useful:
  • required fields are present
  • close is numeric
  • timestamp/date can be handled consistently
  • timeframe is set for daily data, for example 1d
• Add a small normalization helper or documented mapping for converting client data into the internal model.

Out of scope

• No DuckDB implementation in this ticket
• No database schema migration in this ticket
• No full replacement of existing data clients unless a very small adapter is needed

Acceptance criteria

• Internal model types for data sources, instruments and price bars exist
• FX-style exchange-rate data can be represented as a price_bars-style row with the rate stored as close
• OHLCV-style market data can be represented without changing the model
• Required and optional fields are clearly defined in code or documentation
• Model code is independent from UI, database and external API client response formats
• Basic tests cover FX data and OHLCV-style market data
• The model direction matches the storage research in docs/research-databases-and-storage.md
• Existing tests still pass

Note

Priority: Must