feat: return empty relationships for new entities

[elpete]

Closes #177
Closes #148
Closes #131

Issue review

#177 / #131 — empty relationship values for new entities

Recommendation: 9/10. New entities should expose a relationship type's normal empty value instead of forcing loaded-state branching in forms, post-fill defaults, interceptors, and mementos. This should be the default rather than an opt-in setting so a relationship getter has the same value shape on new and loaded entities.

#148 — improve retrieveRelationship()

Recommendation: 9/10. The explicit relationship-cache API should validate names and provide predictable defaults.

Reasons in favor:

• to-one relationships consistently return null or a configured default entity;
• to-many relationships consistently return an empty array;
• callers can seed an explicit default without using internal state;
• invalid names fail close to the call site with a useful exception;
• no meaningless SQL is issued;
• post-fill code can inspect a new entity's relationships without knowing which values were supplied.

Tradeoffs:

• retrieving an unloaded relationship through retrieveRelationship() now marks its default value loaded, so callers choosing this low-level cache API are intentionally suppressing a later lazy-load query;
• relationship definitions are resolved to validate them, so errors inside a real relationship method continue to propagate rather than being mislabeled as a missing relationship;
• direct relationship-builder calls on new entities still throw because querying or mutating from an unpersisted parent remains invalid.

Reproduction

Public API tests reproduced the prior behavior:

• getters on new entities threw QuickEntityNotLoaded, including the Return nulls instead of throwing an error when attempting to access a relationship on an unloaded entity #131 post-fill pattern;
• retrieveRelationship("posts") returned null instead of an empty collection;
• an explicit default argument was ignored;
• an unknown relationship returned null instead of throwing.

Before the #148 implementation, its focused bundle reported 9 passed, 1 failure, and 2 errors.

Implementation

• Initialize new-entity getters through each relationship's existing initRelation() behavior.
• Add a base null initializer for to-one relationships, including polymorphic belongs-to.
• Validate relationship names in retrieveRelationship().
• Return and cache the relationship type default without querying when no value is loaded.
• Accept an optional caller-provided default value and cache it.
• Preserve configured withDefault() entities and empty arrays for collection relationships.
• Keep loaded cached retrieval on the fast path without rebuilding relationship objects.

Validation

• Focused relationship/default/polymorphic suites: 16 passed, 0 failed, 0 errors.
• Full suite: 500 passed, 0 failed, 0 errors, 3 skipped.
• box run-script format
• git diff --check
• Dependency baseline: qb 14.0.0-beta.3 (qb@be).

[elpete]

Issue #131 is the earlier version of #177 and is covered by this implementation’s default behavior. The public regression calls to-one and to-many getters on brand-new entities, verifies null/empty-array results, and verifies no SQL runs. I added Closes #131 and the post-fill use case to the PR review.

[elpete]

Additional issue reviews: #148 and #131

Addresses #148. Fit score: 8/10. retrieveRelationship() should distinguish missing relationship definitions from unloaded relationship values and honor defaults. This branch adds those semantics and public relationship-loading tests.

Addresses #131. Fit score: 7/10. Returning the relationship default for a new entity makes fill/default workflows practical, but globally returning null can hide misspelled relationship names. This implementation keeps helpful errors for nonexistent relationships while returning the defined empty/default value for valid unloaded relationships.