fix(api): handle null createdAt in AuditedUser to prevent admin 500

[blink-claw-bot]

Summary

• Problem: AuditedUser.createdAt is declared Timestamp! (non-null) in the admin GraphQL schema, but translateToUser passes through undefined when the underlying MongoDB document has no createdAt field. This causes HTTP 500 on the admin account details page.
• Fix: Fall back to Unix epoch (new Date(0)) when createdAt is missing/null, signaling "unknown creation date" rather than crashing.
• Test: Added unit test verifying translateToUser returns a valid Date (epoch) for records with missing createdAt, and preserves existing values.

Test plan

• Unit test passes: translateToUser with missing createdAt returns new Date(0)
• Unit test passes: translateToUser with valid createdAt preserves the original value
• Manual: verify admin account details page no longer 500s for users without createdAt

Closes #703

🤖 Review by claude-sonnet-4 via Blink-Claw-Bot

[k9ert]

Fix: Fall back to Unix epoch (new Date(0)) when createdAt is missing/null, signaling "unknown creation date" rather than crashing.

Why does the admin-panel show "unknown creation date" ? Is that a convention somewhere?

[blink-claw-bot]

Good question — the admin panel doesn't literally show "unknown creation date" as text. The Unix epoch fallback (new Date(0) → Jan 1, 1970) just prevents the GraphQL resolver from crashing with a 500 when createdAt is missing on old MongoDB documents. The admin panel will display the epoch date (1970-01-01), which is obviously not a real signup date and effectively signals to anyone reading it that the value is unknown.

It's not a formal convention in the codebase — it was chosen here as the least-disruptive fix. The alternative would be making createdAt nullable in the admin GraphQL schema, which would require updating all admin panel consumers to handle null. Happy to go that route instead if you prefer a cleaner contract.