[DEFECT] Tags portlet ignores new duplicate-detection response from v2 API (silent create dialog, misleading import toast)

Problem Statement

The Tags portlet (libs/portlets/dot-tags) does not surface the duplicate-detection information that PR #34604 added to the v2 Tags API. As a result:

1. Create dialog gives no feedback when a tag already exists. When a user submits a tag name that already exists, the backend now returns 200 OK with created: [] and the existing tag in duplicates[]. The frontend ignores the duplicates list, reloads the table, and shows nothing — the user cannot tell whether their tag was actually created or silently treated as a no-op.

2. Import dialog shows a misleading "success" toast on pure-duplicate imports. The import endpoint now returns a duplicateCount field separate from successCount. The frontend ignores duplicateCount and decides SUCCESS-vs-WARNING based only on failureCount === 0. Re-importing a CSV that contains only pre-existing tags shows a SUCCESS toast saying "0 tags imported" — exactly the misleading behavior the backend fix in #34548 was meant to eliminate.

Severity: Medium — tags get created/imported correctly, but the UX gives users wrong information about what happened.

Affected files:

Steps to Reproduce

Create dialog (silent duplicate):

1. Open the Tags portlet
2. Create a tag named marketing on SYSTEM_HOST
3. Click "Add Tag" and submit the same name marketing again
4. Expected: A toast or message tells the user the tag already exists
5. Actual: The dialog closes, the table reloads, no feedback at all

Import dialog (misleading success):

1. Open the Tags portlet
2. Create tags abc1, abc2, abc3 manually
3. Click "Import" and upload a CSV containing only abc1, abc2, abc3
4. Expected: A WARNING/INFO toast indicating that 3 tags were skipped as duplicates
5. Actual: A SUCCESS toast appears (current code: failureCount === 0 → SUCCESS), claiming the import succeeded even though zero new tags were imported

Acceptance Criteria

• DotTagsService.createTag() return type is updated to { created: DotTag[]; duplicates: DotTag[] } to match the response shape introduced by PR #34604
• DotTagsService.importTags() return type includes the new duplicateCount: number field
• Store / list-component plumbing forwards the created and duplicates payload from createTag() to the UI layer (current handleTagAction discards it)
• When a single-tag create returns created.length === 0 && duplicates.length === 1, the user sees an INFO toast (i18n key: tags.create.duplicate) stating that the tag already exists
• When a batch create returns created.length > 0 && duplicates.length > 0, the user sees an INFO toast summarizing both counts (i18n key: tags.create.mixed)
• When a single-tag create returns created.length === 1 && duplicates.length === 0, the user sees a SUCCESS toast (i18n key: tags.create.success)
• Import toast severity is decided by:
  • failureCount === 0 && duplicateCount === 0 → SUCCESS
  • failureCount === 0 && duplicateCount > 0 → INFO (new i18n key tags.import.with-duplicates, with placeholders for successCount, duplicateCount, totalRows)
  • failureCount > 0 → WARNING (existing tags.import.partial-success, extended to include duplicateCount placeholder)
• All new i18n keys added to English Messages_en.properties; other locales filled or left untranslated per current repo convention
• Unit tests added/updated in dot-tags.service.spec.ts, dot-tags-list.store.spec.ts, dot-tags-list.component.spec.ts, dot-tags-import.component.spec.ts covering: all-duplicate create, mixed create, all-duplicate import, mixed import
• No regression in the existing happy path (all-new create and all-new import still behave as today)

dotCMS Version

Latest from main branch (verified against commit 8938aacf0c). PR #34604 was merged on 2026-02-17.

Severity

Medium - Some functionality impacted

Links

• Backend fix: dotCMS/core#34548 / dotCMS/core#34604
• Verification report (Postman/newman): pass — 24 requests, 49 assertions, 0 failures against local main @ 8938aacf0c
• Freshdesk: NA