Align REST compatibility server with ThetaData v3 parameter and response semantics

[userFRM]

Summary

The current Rust SDK core and generated endpoint runtime look structurally aligned with the typed ThetaData endpoint surface, but the REST-compatible server in tools/server still carries Java-terminal response and parameter assumptions that likely drift from the current ThetaData v3 public REST contract.

This should be tracked separately from PR #204, which is focused on SDK CI hardening and MCP serialization.

Why this matters

ThetaData's v3 beta announcement explicitly says the REST API changed shape while keeping the same functionality. The current server already routes requests using /v3/... conventions, but some request/response behavior still appears to target older Java-terminal compatibility semantics.

Confirmed risk areas

• tools/server/src/format.rs still wraps JSON responses in the old Java-terminal envelope:
  • { "header": { ... }, "response": [...] }
• Current v3 docs show operation responses as direct JSON arrays / typed fields rather than the old envelope.
• tools/server/src/handler.rs only special-cases format=csv; v3 docs advertise csv, json, ndjson, and html.
• Query normalization likely still needs v3 compatibility support for:
  • expiration=*
  • strike=*
  • right=both
  • broader date acceptance (YYYY-MM-DD as well as YYYYMMDD)

Sources

• v3 docs example and parameter semantics:
  • https://docs.thetadata.us/operations/option_history_quote.html
  • https://docs.thetadata.us/operations/option_history_greeks_all.html
• Current server implementation:
  • tools/server/src/format.rs
  • tools/server/src/handler.rs
  • tools/server/src/router.rs

Proposed work

• Audit tools/server against current ThetaData v3 docs endpoint-by-endpoint.
• Remove or gate the old JSON envelope where v3 expects direct JSON arrays/objects.
• Add explicit support for ndjson and html output modes where documented.
• Normalize wildcard and enum-style query inputs to match v3 docs (*, both, date formats).
• Add compatibility tests against documented v3 examples.

Nice-to-have

• If needed, split the server into:
  • a true v3-compatible REST surface
  • an optional legacy-compat mode for old Java-terminal consumers

[userFRM]

Closing as superseded. The concern here was driven by a July 9, 2025 beta announcement, which we no longer want to use as a current architecture driver. Current official docs, the provided proto, and live behavior are the authoritative sources instead.