test: verify relationship fill does not persist

[elpete]

Closes #120

Review

The requested workflow is a good fit for Quick: applications should be able to construct a related entity, populate it, and defer persistence. Quick already exposes this as parent.relationship().fill( attributes ), which creates a new entity and pre-populates the relationship foreign keys without saving it.

Recommendation: 9/10.

Reasons for

• Enables aggregate construction and validation before database writes.
• Keeps relationship foreign-key assignment inside Quick.
• Separates construction from persistence without adding a positional boolean to create().
• Matches Quick's existing fill() vocabulary.

Reasons against

• A second construction API adds discoverability/documentation surface.
• The legacy newPost.author().associate( user ) pattern remains blocked for unloaded entities; callers should use the relationship's fill() method or the generated relationship setter.

Attempted implementation/reproduction

The requested capability is already implemented on current next: BaseRelationship#fill calls newEntity(), pre-associates the new model to its parent, fills the supplied attributes, and does not save.

I also tested the issue's old direct author().associate() shape. It still raises QuickEntityNotLoaded, intentionally preserving the guard against querying relationships from unhydrated models. Weakening that global guard would be a larger and riskier semantic change than the requested unsaved-related-entity helper.

This PR strengthens the public relationship test by asserting that only the parent lookup query runs. Creating and filling the related post performs no INSERT or UPDATE.

Validation

• Focused relationship-loading spec: 7 passed, 0 failed, 0 errors
• Full suite: 495 passed, 0 failed, 0 errors, 3 skipped
• Formatter completed
• git diff --check passed