FINERACT-2782: Add UpdateEmailCommandHandler for /v1/email UPDATE endpoint

[AshharAhmadKhan]

Description

EmailApiResource exposes CREATE, RETRIEVE, UPDATE, DELETE endpoints for
/v1/email. CREATE and DELETE have working @CommandType handlers; UPDATE
does not, so calling the UPDATE endpoint throws UnsupportedCommandException
despite the endpoint existing and being documented.

Everything downstream of the handler already exists and is correct:

• EmailWritePlatformService.update(Long, JsonCommand) — interface method
  already declared
• EmailWritePlatformServiceJpaRepositoryImpl.update(...) — already
  implemented
• EmailApiResource.java — already calls
  CommandWrapperBuilder().updateEmail(resourceId)
• UPDATE_EMAIL permission — already exists in
  0002_initial_data.xml, same pattern as CREATE_EMAIL/DELETE_EMAIL

The only missing piece was the command handler itself, routing
@CommandType(entity="EMAIL", action="UPDATE") to the existing service
method. This PR adds that handler, matching the structural pattern of
CreateEmailCommandHandler and the sibling UpdateEmailCampaignCommandHandler.

Note: no test coverage exists for the /emails resource at any layer, and
a separate, pre-existing validator bug was found while investigating this
(EmailDataValidator validates against the wrong resource's constants,
ScheduledEmailConstants instead of EmailApiConstants). Both are tracked
and will be addressed in a separate ticket/PR, since they are independent
of this handler-wiring fix.

See https://issues.apache.org/jira/browse/FINERACT-2782

[AshharAhmadKhan]

hey @adamsaghy , flaky failure please retrigger when you can.

[AshharAhmadKhan]

hey @adamsaghy , please trigger checks when you can, thanks!

[AshharAhmadKhan]

hey @adamsaghy , failure is unrelated to my code. Please retrigger that check, thanks!

[AshharAhmadKhan]

hey @adamsaghy , this is ready for review. Please let me know if you would like any changes.

[AshharAhmadKhan]

not sure why my branch is out of date...

[adamsaghy]

not sure why my branch is out of date...

You can ignore this....

[adamsaghy]

Now we have a working API, lets write an integration or E2E test for it ;)

[AshharAhmadKhan]

i see haha, i was confused whats happening and was about to rebase again.

[AshharAhmadKhan]

Now we have a working API, lets write an integration or E2E test for it ;)

hey adam, regarding the integration/E2E test, I think we should get #6330 merged first. It fixes the EmailDataValidator using the wrong ScheduledEmailConstants, which currently causes valid /v1/email CREATE requests using the actual email API parameters to be rejected. you merged #6331 which fixes the CREATE NPE, so #6330 is the remaining prerequisite for getting a clean end-to-end CREATE → UPDATE flow. Once #6330 is merged, I can add the integration/E2E test on top of this PR.

[AshharAhmadKhan]

Now we have a working API, lets write an integration or E2E test for it ;)

Hey Adam, I don't want to add tests to this PR. I'd rather create a separate PR for that.

I confirmed there's no integration or E2E test coverage for /v1/email at any layer right now, so I'll write a single integration test covering the full lifecycle, CREATE, RETRIEVE, UPDATE, DELETE, against /v1/email.

All four operations share the same setup, so testing them together in one test validates the real end to end flow rather than isolated fragments.

I'll do this once #6330 is merged, since CREATE needs the validator fix in that PR to accept the real request params. What do you think?