Validate: validate email shape at the DTO layer

[Baskarayelu]

Summary��validate email shape at the DTO layer.��## Background��We want to keep the credential-issuance API auditable and sa

e to change. Landing this issue tightens one speci
ic corner and gives reviewers a clear di

to reason about rather than a general "cleanup" commit. It should be scoped small enough to close in a single PR.��## Acceptance criteria��- [ ] The change matches the summary above.�- [ ] Tests cover the new behavior (happy path + one e
plicit
ailure mode).�- [ ] Lint, type-check, and tests all pass locally.�- [ ] PR description re
erences this issue with Closes #<this-issue>.��## Implementation hints��- Reject bad input at the boundary, not deep inside the call graph.�- Errors returned to the caller must be structured (typed enum / JSON code), never a stringly-typed 400.�- Add a test
or each new rejection branch.��## Repo-speci
ic notes��- Node.js/TypeScript service. Install with npm ci and run npm test / npm run lint be
ore pushing.�- Follow the e
isting NestJS module layout — controllers thin, services own business logic.�- Prisma is the ORM; add new tables via prisma migrate dev --name <slug> and commit the generated migration.�- Do not log credential payloads in plainte
t — use the e
isting RedactedLogger.��## Out o
scope��- Unrelated re
actors in adjacent
iles.�- Stylistic-only changes (
ormatting, renaming) that are not required by the
i
.�- Anything beyond the acceptance criteria above; sur
ace
ollow-ups as separate issues.��## How to claim and submit��
. Comment on this issue saying you'd like to take it on; wait
or a maintainer to assign you (avoids duplicated e

ort).�2. Open a PR that re
erences this issue (Closes #<this-issue>).�3. Make sure CI is green and request review
rom a CODEOWNERS maintainer.�4. PRs that close this issue and pass review may quali
y
or a reward — see the MAYBE REWARDED label and the FWC26 campaign page.��---��Category: validation  ·  Campaign: GrantFo
OSS · O

icial Campaign | FWC26 · Maybe Rewarded

[Falcone747]

Hi, I’d like to take this on. I’ll enforce email validation at the DTO boundary, preserve the project’s structured error behavior, add explicit valid/invalid coverage, and run the repository lint/typecheck/test gates before review. Happy to wait for maintainer assignment before starting implementation.