fix(admin): 409 (not 500) on duplicate menu / group code

[jlc488]

Consistency gap found by auditing every create endpoint after the menu duplicate surfaced during integration testing — you asked me to check whether other resources had the same problem, and two did.

The gap

GlobalExceptionHandler maps IllegalStateException → 409 CONFLICT, and User / Role / Permission / Tenant services all do a findBy…isPresent() pre-check and throw it on a duplicate. But MenuAdminService.create and GroupService.create had no such check — they went straight to repository.save(), hit the uq_platform_{menu,group}_tenant_code unique constraint, and bubbled a DataIntegrityViolationException that no handler caught → 500 instead of 409.

The fix

Both tables already declare the unique constraint; this just adds the friendly pre-check the other four resources already had:

• JpaPlatformGroupRepository / JpaPlatformMenuRepository: new findByTenantIdAndCode(tenantId, code).
• GroupService.create / MenuAdminService.create: throw IllegalStateException("… already exists …") when a row with the same (tenantId, code) exists.

Verified end-to-end (running sample-app)

POST /menus  {code: dup.menu.test}  → 201 then 409
POST /groups {code: dup-grp}        → 201 then 409
POST /roles  {code: PLATFORM_ADMIN} → 409 (unchanged, sanity check)

Known limitation (documented, not fixed)

There's still a narrow race between the pre-check and the insert under concurrent creates — the DB constraint is the real guard and would 500 in that rare window. Catching DataIntegrityViolationException in GlobalExceptionHandler would close it, but I left that out to keep the change minimal and consistent with the existing four services, which share the same theoretical race. Worth a follow-up if you want belt-and-suspenders.

Context

5th item from integration verification. The full audit of create endpoints confirmed only menu + group were affected; the not-found path (IllegalArgumentException → 400) is uniform across all resources and was left as-is.