Fix 500 when removing a profile picture

[HafizMMoaz]

Fixes #94.

Root cause

users.avatar is varchar(255) NOT NULL DEFAULT 'avatar.png'. Clearing the MediaPicker submits an empty string, and Laravel's ConvertEmptyStringsToNull turns that into null before it reaches validation, so ProfileController::update() saved a null into a NOT NULL column:

SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'avatar' cannot be null

Hence the 500, the picture never being removed, and no message reaching the user. Reproduced directly against the column before fixing.

The old guard if ($user->wasChanged('avatar') && $user->avatar) also skipped the clear case, so even without the constraint error avatar_media_id would have stayed pointing at media that no longer represented the user, which is the part the issue's suggested fix covers.

Change

• Clearing the avatar now falls back to the default placeholder instead of null. "No avatar" is avatar.png in this schema, never null, which is the convention AuthApiController and BackfillMediaAttachments already follow.
• The media link is cleared as well as set, so removing a picture nulls avatar_media_id.
• An update that omits avatar entirely still leaves the existing picture alone, since validated() only returns keys the request actually sent.
• The placeholder value moves into User::DEFAULT_AVATAR alongside a hasCustomAvatar() helper, so the magic string is not spread further.
• The profile form treats the placeholder as empty, so a user with no picture sees the placeholder icon and no clear button, instead of a clear button with nothing to clear.

Tests

New tests/Feature/ProfileAvatarTest.php, 4 tests / 13 assertions, all passing:

✓ avatar can be removed without a server error
✓ removing the avatar clears the media link
✓ an omitted avatar leaves the existing one alone
✓ the default placeholder does not count as a custom avatar

They live in their own file rather than in ProfileTest because ProfileTest is red on main for an unrelated reason: it uses RefreshDatabase with factory users that carry no permissions, so every request 403s on ProfileUpdateRequest::authorize()'s edit-profile check. These follow the DatabaseTransactions + explicit permission grant pattern that UserCreationTest uses and that does pass. Worth a separate issue.

npx tsc --noEmit is clean.