CMake good first issues

This issue reports a potential bug in the `BsdfDwaFabric` component, specifically within the `eval` function. The developer notes an inconsistency between the scalar and GPU implementations regarding the handling of shading normals, which might be causing a "soften hard shadow terminator" effect. They are questioning if this discrepancy constitutes a bug.

The user requests that the "Geometry Statistics" table output in Moonray be sorted by the "Face Count" column in descending order. This would make it easier to identify the largest geometry elements at a glance, as the current unsorted output can be difficult to parse.

This issue proposes a new feature to enhance the render log by including all scene variables at the top. Default values should be marked with an asterisk, and the variables should be sorted alphabetically for better readability and organization.

This issue reports a CMake deprecation warning related to the FindTBB.cmake module during the build configuration process. The warning indicates that compatibility with older CMake versions (prior to 3.5) will be removed in the future, suggesting an update to the `cmake_minimum_required` version in the `FindTBB.cmake` file.

A bug has been identified in the simulation where the collision mesh for the robot's legs is incomplete, specifically missing the wheel motor geometry. This omission leads to inter-leg collisions during lateral leg lift and landing maneuvers, as the actual motor bodies are not accounted for in the simulation's physics.

This issue aims to unify and clarify the documentation for the JSON module, ensuring it accurately reflects public behavior and API contracts. It involves reviewing and updating various documentation files, examples, and header comments to address inconsistencies in areas like ownership semantics, integer ranges, JPath mutations, and error handling.

This issue proposes adding compile tests to ensure each public JSON header can be included and compiled independently. The goal is to verify that no header relies on being included through an umbrella header, guaranteeing that each public header is self-sufficient and correctly declares its dependencies.

This issue aims to refactor the JSON module's CMake configuration to prevent it from globally modifying parent CMake variables. The goal is to ensure that the JSON module's requirements are scoped to its own targets, avoiding unintended side effects on umbrella builds and other unrelated targets. This involves reviewing and adjusting settings like C++ standard, position-independent code, and output directories.

This issue proposes adding an optional durability mode to JSON file writes. When enabled, this mode will ensure that data and metadata are written to stable storage before the `dump_file()` function returns, preventing data loss in case of system crashes. The feature will be opt-in to maintain default performance and will include platform-specific implementations.

This issue proposes adding a reusable options structure for JSON serialization, improving readability and extensibility beyond current positional parameters. The goal is to support compact, pretty, and indented output, along with ASCII escaping, while maintaining backward compatibility with existing overloads.

This issue aims to improve compile-time diagnostics for the `o()` object builder in the JSON module. The goal is to provide more concise and informative error messages when invalid key types or malformed argument sequences are used, pinpointing the exact location of the error. This will involve adding compile-time key validation and ensuring compatibility with existing usage.

This issue proposes adding semantic equality comparison for the `Simple` JSON value type. Currently, direct comparison of `Simple` values can lead to comparing pointer identities instead of actual content. The goal is to enable recursive, value-based equality checks for tokens, arrays, and key-value pairs, independent of memory addresses, and to clearly define object property order and duplicate key handling.

This issue aims to add comprehensive round-trip tests for JSON and Simple value conversions. The goal is to ensure that data remains semantically preserved when converting between these two representations in both directions (Simple to Json and Json to Simple). The tests will cover various data types, nested structures, and edge cases, while explicitly identifying and documenting values that cannot be represented losslessly.

This issue proposes adding a new feature to recursively convert `vix::json::Json` values into a lightweight Simple value model. Currently, only conversion from Simple types to Json exists, and this change aims to provide the inverse, handling various Json types like null, booleans, numbers, strings, arrays, and objects, with clear error handling for out-of-range values and depth protection.

This issue proposes adding explicit JPath erase operations to the JSON module, enabling safe deletion of object members and array elements. The current JPath implementation only supports reading and assignment, requiring manual parent resolution for deletions. The new functionality will include clear behavior for various deletion scenarios, such as missing or invalid paths, and will offer both throwing and safe variants.

This issue addresses the handling of escape sequences within quoted keys in JPath expressions. Currently, unsupported escape sequences are silently ignored, potentially leading to incorrect key lookups. The goal is to define and validate supported escape sequences, ensure consistent behavior for unsupported ones, and improve error reporting for invalid escapes.

This issue aims to standardize the behavior of JPath expressions in the JSON module, specifically addressing how empty segments, trailing dots, and other boundary cases are handled. The goal is to ensure deterministic and documented behavior for all valid and invalid JPath syntaxes, preventing silent misinterpretations and improving robustness.

This issue addresses a bug in the JSON module where null C-string pointers passed to various functions can cause undefined behavior. The goal is to explicitly define and safely handle null pointer inputs for all public C-string overloads, ensuring clear error reporting for throwing APIs and graceful failure for safe APIs, while preserving existing behavior for valid inputs.

This issue aims to improve the robustness of JSON file loading by ensuring that all file I/O operations (seeking, size retrieval, and reading) are validated before the data is passed to the JSON parser. Currently, partial reads can lead to misleading JSON syntax errors, and this fix will ensure I/O failures are reported as distinct file-read errors.

This issue proposes refactoring the ORM module to centralize shared field type declarations, eliminating duplication and reducing unnecessary dependencies in public headers. The goal is to improve header ownership clarity and simplify include management without altering repository behavior or adding new features.

This issue proposes enhancing the `QueryBuilder` to support structured construction of common SQL operations like SELECT, INSERT, UPDATE, and DELETE. The goal is to provide a more user-friendly way to build SQL queries while still allowing raw SQL access and maintaining separation of values from SQL.

This issue proposes adding explicit relationship metadata and loading capabilities to the ORM. Developers will be able to define relationships (one-to-one, one-to-many, many-to-one) and explicitly request their loading, avoiding hidden lazy queries. The implementation will involve defining relationship metadata, supporting different relationship types, and ensuring explicit loading through repository methods.

This issue proposes adding optional soft-delete functionality to the ORM. Instead of physically deleting entities, repositories can be configured to mark them as deleted by updating a specific column. This feature will allow for exclusion of deleted items from normal reads, explicit access to deleted items, and restoration, while preserving physical deletion for standard repositories.

This issue proposes adding support for composite (multi-column) keys in the ORM's repository operations. Currently, repositories only support single-column keys, forcing custom implementations for tables with composite keys. The goal is to allow explicit, ordered composite keys for find, existence, update, and delete operations while maintaining backward compatibility for single-column keys.

This issue proposes to enhance the ORM's repository functionality to support non-integer primary keys, such as unsigned integers, strings, and UUIDs. The goal is to generalize lookup, update, existence, and deletion operations to accommodate a wider range of database-compatible scalar identifiers while maintaining existing `std::int64_t` overloads.

This feature request aims to add built-in support for `std::chrono` date and time types within the ORM. Currently, developers must manually convert these types to strings or integers, leading to boilerplate code. The goal is to provide documented, stable codecs for common temporal representations, including handling UTC, precision, and storage formats, with integration tests for SQLite and MySQL.

This issue proposes adding support for `std::optional<T>` values at the ORM mapper boundary. The goal is to allow empty optionals to map to SQL NULL and populated optionals to undergo normal value conversion, simplifying the handling of optional scalar types.

This issue proposes adding explicit "upsert" (insert or update) functionality to the ORM. Currently, developers must manually handle conflict detection or write database-specific SQL. The new feature will provide a portable upsert request that delegates SQL generation to dialect-aware implementations for SQLite, MySQL, and PostgreSQL, while ensuring conflict targets and update fields are explicitly defined.

This issue proposes adding support for partial updates to the ORM's repository functionality. Currently, `updateById()` updates all fields returned by `toUpdateFields()`, forcing manual SQL or custom methods for partial updates. The goal is to allow specifying a list of fields to update, preserving the existing full update behavior.