v0.3.0 - Professional Error Handling & API Hardening

⚠ Breaking Changes

• Error Handling Implementation: The library now uses a custom BybitError type (via thiserror) instead of generic anyhow::Result.
  • Action Required: Update your error handling code to match BybitResult<T> or Result<T, BybitError>.
• Response Type Changes: All client methods now return BybitResult<ServerResponse<T>>.
  • This provides access to ret_code, ret_msg, time, and ret_ext_info alongside the result.
  • Action Required: You may need to access .result on the returned response to get the data payload.
• Flattened API Structure: Module paths have been simplified for better ergonomics.
  • use bybit_rust_api::enums::category::Category -> use bybit_rust_api::Category
  • Action Required: Update your import paths. Common types (Category, Side, OrderType etc.) are now available at the crate root.

🚀 Features & Improvements

• Automatic API Error Validation: The client now explicitly checks retCode in every response. If non-zero, it returns a strongly typed BybitError::Api(ErrorCode), allowing you to handle specific exchange errors (e.g., Insufficient Balance) programmatically.
• Robust Error Parsing: Implemented a two-stage deserialization (Raw -> Result) to ensure that API errors are never masked by JSON parsing failures, even if the error response structure differs from the success response.
• Thread Safety: Confirmed full Send + Sync support for multi-threaded applications.
• Documentation: added comprehensive crate-level documentation and a "Quick Start" guide in lib.rs and README.md.

🐛 Bug Fixes

• Critical POST Signature Fix: Fixed a major bug where POST request signatures were being generated using URL-encoding instead of JSON stringification. This restores full functionality for trading endpoints on V5.
• Linting: Resolved all clippy warnings and standardized code style.

📦 Dependencies

• Switched to thiserror for library-grade error types.