feat: guard loaded entity keys from mutation

[elpete]

Closes #43

Issue review

Fit score: 8/10. A loaded entity’s primary key is its identity and is used to target writes and relationships. Letting it drift currently produces a particularly dangerous silent result: the save targets the replacement key and may update no row.

Reasons for

• turns silent no-op or wrong-row behavior into an actionable error
• makes entity identity immutable after loading
• handles all components of composite keys

Reasons against

• applications intentionally changing natural primary keys must create a new entity or use a direct query
• generated CFML setters cannot be intercepted at assignment time, so the guard runs when Quick synchronizes/persists the entity

Implementation

• throws QuickPrimaryKeyMutationException when a loaded entity key differs from its original value
• permits assigning the same key value
• records original keys before Quick creates loaded relationship references from raw IDs

Reproduction

The new public-API regression failed before the fix: findOrFail( 1 ).setId( 2 ).save() did not throw and silently targeted the replacement key.

Validation

• focused save and has-many coverage: 34 passed, 0 failed, 0 errors
• full suite: 498 passed, 0 failed, 0 errors, 3 skipped
• box run-script format
• git diff --check
• qb dependency: 14.0.0-beta.3