Added Structured logs for creator list query

[dubemoyibe-star]

Creator List Mapper – Runtime Type Validation

What's changed

The creator list mapper had no way to detect when a database field came back as the wrong type — for example, a column that used to be a Date silently becoming a string after a migration. By the time that reaches the client, it's either been coerced quietly or caused a runtime error with no useful context in the logs.

This PR adds runtime type checking inside mapCreatorListItem so that any type mismatch on a projected field is caught early and surfaced as a structured error-level log entry — before the bad value reaches the response.

What was added

logIfFieldTypeMismatch — a new function in creator-list-item.mapper.ts that checks each field from CREATOR_LIST_DEFAULT_SELECT against its expected runtime type (string, boolean, or Date). It skips null/undefined values (those are already handled by the existing null-field warning) and only fires when a non-null value is the wrong type.

The log entry includes fieldName, expectedType, receivedType, creatorId, and requestId for easy correlation in any log aggregator.

Client response behavior is unchanged — the mismatched value still passes through as-is. This is intentional; the log is an early warning signal, not a blocker.

Tests

Extended creator-list-item.mapper.test.ts with three new cases:

• A string field receiving a number fires the error log with the correct field/type metadata
• A Date field receiving a string fires the error log
• Correctly typed fields produce no error log

The existing null-field warning tests are untouched and still pass.
Closes #404

[drips-wave]

@dubemoyibe-star Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits