[Feature][Medium] Expand unit test coverage for core SDK operations

[numbers-official]

Summary

The current test suites in both Python and TypeScript SDKs only cover initialization, validation, and searchAsset() request/response handling. Core operations that interact with the API lack unit tests with mocked HTTP responses.

Missing Test Coverage

Both SDKs:

• register() — No tests verifying multipart form construction, signing flow, or file normalization with mocked API
• update() — No tests verifying PATCH request construction or metadata serialization
• get() — No tests verifying GET request and response parsing
• getHistory() / get_history() — No tests verifying history API URL construction, query parameters (especially testnet flag), or commit response parsing
• getAssetTree() / get_asset_tree() — No tests verifying the two-step flow (history fetch → merge request) or AssetTree response parsing
• searchNft() / search_nft() — No tests verifying NFT search request or response parsing

Python-specific:

• python/tests/test_asset_search.py and python/tests/test_asset_tree.py exist but only cover searchAsset and getAssetTree partially
• No tests for _normalize_file() with Path objects or error cases

TypeScript-specific:

• ts/src/client.test.ts only tests searchAsset request/response and constructor validation
• No tests for normalizeFile() with different input types (File, Blob, Buffer)

Suggested Approach

1. For each untested method, create test cases that:

   • Mock the HTTP client (respx for Python, vi.fn for fetch in TypeScript)
   • Verify correct URL construction and headers
   • Verify request body format (multipart, JSON, query params)
   • Verify response parsing into typed SDK objects
   • Test error handling for various HTTP status codes

2. Aim for >80% line coverage across both SDKs.

Priority

Medium — the SDK works correctly based on integration testing, but unit tests would catch regressions faster and improve contributor confidence.