fix: mass-assignment on update:

[techmahedy]

Root cause: save()-as-update and update(array $attributes) only applied the $creatable whitelist filter if (!empty($this->creatable)) — so any model that never declared $creatable (legal, since only insert enforced it) would persist every dirty attribute unfiltered on update, including attacker-supplied keys from update($request->all()).

Fix (InteractsWithModelQueryProcessing.php):

Extracted the insert-path's throw into a shared assertCreatableIsDefined(), now called on both save()'s update branch and update() — a model must declare $creatable to be persisted at all, insert or update, matching the guarantee that already existed for insert.

Made the $creatable intersect on the dirty-attribute diff unconditional (previously skipped when $creatable was empty).
update() now also filters the incoming $attributes array against $creatable before ever calling setAttribute() — so non-whitelisted keys (e.g. id, role) never even land on the in-memory model, not just get dropped at persistence time.

Left fill() and model hydration (Builder.php row-loading, Model::__construct()) completely untouched — those load full DB rows including PK/timestamps and would break if guarded the same way. The vulnerability was specifically in the two request-facing write paths, not in hydration.