fix(records): reject two lower or two upper bounds in TimeRange

[andersfylling]

The API rejects a range carrying both gte and gt (or both lte and lt), and the TimeRange docstring already says so, but the constructor builds it anyway and the request only fails server-side:

TimeRange(gte=1, gt=2).dump()   # {'gte': 1, 'gt': 2}

Now a ValueError at construction, where the mistake is.

The fake resource generator behind the generic round-trip tests fills every field, so it gets a special case — the same way DataPointSubscriptionWrite already has one for its mutually exclusive arguments. That change ships here, otherwise test_base.py breaks the moment this merges.

First commit is the failing tests, second is the fix.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.83%. Comparing base (d7806bd) to head (ea4f159).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2752      +/-   ##
==========================================
+ Coverage   93.77%   93.83%   +0.05%     
==========================================
  Files         509      509              
  Lines       52252    52269      +17     
==========================================
+ Hits        48999    49045      +46     
+ Misses       3253     3224      -29     

Files with missing lines	Coverage Δ
...gnite/client/data_classes/data_modeling/records.py	98.24% <100.00%> (+0.04%)	⬆️
...s_unit/test_api/test_data_modeling/test_records.py	100.00% <100.00%> (ø)

... and 10 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.