Add optional FXMacroData data client

[roberttidball]

Summary

• Add an optional FXMacroData data client in wickra-backtest-data.
• Gate live HTTP behind a new fxmacrodata feature using the existing optional provider pattern.
• Re-export the module from the facade crate when the feature is enabled.

Tests

• cargo test -p wickra-backtest-data fxmacrodata
• cargo test -p wickra-backtest-data fxmacrodata --features fxmacrodata

[codecov]

Welcome to Codecov 🎉

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

ℹ️ You can also turn on project coverage checks and project coverage reporting on Pull Request comment

Thanks for integrating Codecov - We've got you covered ☂️

[kingchenc]

Hey @roberttidball — thanks a lot for this, and congrats on your first contribution to the project. Really appreciate you taking the time.

The code is clean, and it's clear you read the codebase: gating the live HTTP behind a fxmacrodata feature while keeping the URL builder always-on and offline-tested is exactly the pattern the Binance client uses. Nice.

Since it's still a draft, a few things to bring it fully in line with the rest of the crate:

• Docs — we document every public item with ///, and each file has a //! header; the new module doesn't have any yet.
• CHANGELOG — add an ### Added bullet under [Unreleased].
• Error prefixes — we use a lowercase provider tag (binance klines: ...), so fxmacrodata: ... would match.
• Error-path tests — a couple of is_err() tests for the required-field paths would round it out (see binance_klines_reject_short_rows).
• Module layout — the data crate currently keeps everything in a single lib.rs (the Binance client lives inline behind its own #[cfg]), so a separate fxmacrodata.rs is a small break from that. At ~300 lines a dedicated file is honestly defensible, so treat this as an open question rather than a blocker.
• Default reads the environment — it pulls FXMACRODATA_API_KEY/FXMD_API_KEY in Default::default(). We tend to keep env reads out of Default and behind an explicit constructor (e.g. from_env()) so the default is side-effect-free. Pure nitpick.

One design question before going further: everything in wickra-backtest-data produces a typed Candle stream for the engine, whereas this returns raw serde_json::Value. Is the idea that callers parse the macro payloads themselves, or would it make sense to shape at least the calendar/COT responses into a small typed struct? Fine either way — just want it to fit how the data crate is meant to be consumed.

Thanks again — good stuff.

[roberttidball]

Addressed the draft review checklist in the latest push:

• Added module and public-item docs.
• Added the [Unreleased] changelog bullet.
• Switched FXMacroData error text to the lowercase fxmacrodata: provider prefix.
• Added required-path error tests.
• Moved environment reads out of Default and into explicit from_env().
• Added typed release-calendar and COT response parsers while keeping raw JSON fetch support for broader endpoint coverage.

Validation:

• cargo fmt --all
• cargo build --workspace
• cargo test --workspace --all-features
• cargo clippy --workspace --all-targets --all-features -- -D warnings

I could not run cargo deny check locally because the cargo-deny subcommand is not installed in this environment.