Composite attribute support

[colemancda]

Adds composite attribute support, following CoreModel #11. Requires CoreModel 2.11.0.

Storage

Composites are expanded into one natively-typed column per leaf element, at any nesting depth — the same strategy CoreData uses, established by reverse engineering a Core Data SQLite store rather than guessing:

CREATE TABLE Facility (
    "name"                       TEXT,
    "location.latitude"          REAL,
    "address.location.latitude"  REAL   -- nested, flattened all the way down
);

Two deliberate deviations from CoreData:

• Columns are named by full dotted path rather than CoreData's leaf-name-plus-numeric-suffix (ZLATITUDE, ZLATITUDE1). Path names are deterministic and need no persisted mapping. They also mean PredicateKeyPath.rawValue is the column name, so element predicates and sorts need no rewriting — location.latitude > 30 compiles to a plain column reference, no json_extract.
• A composite as a whole has no column, so comparing one is rejected rather than silently mis-compiled.

Known limitation

An expanded column layout cannot distinguish an absent composite from one whose elements are all null, so the latter reads back as .null. This is inherent to the strategy and matches CoreData exactly (verified empirically). Covered by absentCompositeIsNull.

Also included

.arithmetic expressions (new in CoreModel 2.11.0) are rejected with invalidPredicate rather than silently mis-translated. Actually implementing arithmetic in SQL is separate work, marked TODO.

Testing

10 new tests: column expansion, a schema assertion that leaves are real REAL/TEXT columns, nested round-trips, element and nested-element predicates, sorting, partial and absent composites, and rejection of whole-composite comparison. All 117 tests pass against real SQLite files.