feat(records): support views as record sources and in property references

[evertoncolling]

Description

This PR extends the SDK to support using record views to read and write records: as a source when writing and reading records, and in property references for filters, aggregates, and target units.

No breaking changes. Records remains an alpha feature behind FeaturePreviewWarning.

Checklist:

• Tests added/updated.
• Documentation updated. Documentation is generated from docstrings - these must be updated according to your change.
  If a new method has been added it should be referenced in cognite.rst in order to generate docs based on its docstring.
• The PR title follows the Conventional Commit spec.

[gemini-code-assist]

Code Review

This pull request adds support for referencing views as record sources across various data modeling operations, including ingest, upsert, aggregate, filter, and sync. It introduces the RecordViewId class and updates relevant data classes, validation logic, and unit tests. Feedback on the changes suggests using .load(data) instead of direct dictionary key access when parsing record source identifiers to robustly handle both camelCase and snake_case formats and prevent potential KeyErrors.

[codecov]

Codecov Report

❌ Patch coverage is 98.90110% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 93.14%. Comparing base (f6aaabd) to head (26697e0).
⚠️ Report is 13 commits behind head on master.

Files with missing lines	Patch %	Lines
cognite/client/data_classes/filters.py	88.88%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2801      +/-   ##
==========================================
+ Coverage   93.08%   93.14%   +0.05%     
==========================================
  Files         516      516              
  Lines       53386    53851     +465     
==========================================
+ Hits        49697    50158     +461     
- Misses       3689     3693       +4     

Files with missing lines	Coverage Δ
cognite/client/_api/data_modeling/records.py	99.04% <ø> (ø)
cognite/client/_sync_api/data_modeling/records.py	100.00% <ø> (ø)
...nite/client/data_classes/data_modeling/__init__.py	100.00% <ø> (ø)
...e/client/data_classes/data_modeling/_validation.py	93.54% <100.00%> (+2.63%)	⬆️
...te/client/data_classes/data_modeling/aggregates.py	99.60% <100.00%> (ø)
cognite/client/data_classes/data_modeling/ids.py	94.30% <100.00%> (+0.11%)	⬆️
...gnite/client/data_classes/data_modeling/records.py	98.55% <100.00%> (+0.33%)	⬆️
...s_unit/test_api/test_data_modeling/test_records.py	100.00% <100.00%> (ø)
...nit/test_data_classes/test_data_models/test_ids.py	100.00% <100.00%> (ø)
tests/tests_unit/test_data_classes/test_filters.py	100.00% <100.00%> (ø)
... and 1 more

... and 26 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.

[haakonvt]

Good stuff, here's a few comments 😉

[haakonvt]

Maybe I don't understand the point with RecordContainerId, but shouldn't this be just that, a RecordContainerId?

If you want ContainerId to cover both instances+records then what's the point of having RecordContainerId?

[evertoncolling]

Restored RecordContainerId in the fixture and kept generic ID coverage in dedicated tests. The record-specific name communicates intent. Eligibility depends on the resource's usedFor metadata, not its ID class. ed8ae75