feat: fill relationships on new entities

[elpete]

Closes #179

Issue review

Recommendation: 8/10 for in-memory aggregate construction; not for implicit aggregate persistence. Building a relationship graph before persistence is a strong fit for Quick because it enables validation and removes an artificial create/update difference. Automatically saving that graph is not a fit: Quick intentionally makes persistence boundaries explicit, and a cascading save() would look too much like a unit-of-work API while lacking those guarantees.

Behavior

• fill() on a new entity accepts relationship data.
• Related attribute structs are normalized into unloaded Quick entities and cached on the root, so normal relationship getters expose the graph for validation.
• create() / save() persists only the root entity.
• Related entities remain unloaded and belong-to-many identifiers remain only in the in-memory relationship cache.
• Callers explicitly choose how and when to persist or attach each relationship through the existing relationship APIs.

Test-first revision

I first changed the public create() regressions to require root-only persistence. Against the prior cascading implementation, the focused run had 14 passes and 2 failures: child entities were loaded/persisted, and belongs-to-many identifiers had been resolved and attached. After removing deferred relationship writes, all 16 focused specs pass.

The existing public fill() regression also verifies that an entity and a child struct both become unloaded Quick entities in the cached relationship graph.

Validation

• Red phase: 14 passed, 2 failed, 0 errors.
• Green phase: focused CreateSpec, FillSpec, and GoodErrorMessagesSpec suites have 16 passed, 0 failed, 0 errors.
• box run-script format
• git diff --check

Dependency: qb 14.0.0-beta.3.