feat(myopencre): improve UI messaging for no-op CSV imports

[PRAteek-singHWY]

⚠️ This PR depends on:

• feat(myopencre): improve CSV import error handling in UI #683 — Frontend CSV import error handling

Please review this PR after the above PR is merged.

---

NOTE FOR REVIEWERS

This PR intentionally limits its scope to the following files only:

• application/frontend/src/pages/MyOpenCRE/MyOpenCRE.tsx
• application/web/web_main.py

Any additional file diffs shown by GitHub are inherited from branch history or stacked branches and are not part of this change.

---

Summary

This PR improves the MyOpenCRE CSV import user experience by clearly distinguishing successful no-op imports from imports that actually create new data.

A no-op import occurs when:

• The uploaded CSV is valid but contains no importable rows (e.g. headers only), or
• The CSV re-uploads mappings that already exist (idempotent import)

Previously, these cases appeared ambiguous or misleading in the UI.
This change ensures users receive accurate, intention-revealing feedback while keeping all existing backend behavior unchanged.

---

What this PR does

✅ Explicit no-op import feedback (frontend)

• Detects successful imports where:
  • new_cres.length === 0
  • new_standards === 0
• Renders a neutral informational message instead of a success or error state
• Clearly communicates that:

  The import completed successfully, but no changes were made

✅ Empty CSV handling

• Shows an informational message when:
  • A CSV contains only headers or padding rows
  • No rows are importable after backend filtering

✅ Preserves existing success behavior

• Imports that create new CREs or standards continue to show:
  • Green success message
  • Accurate creation counts

✅ UI consistency improvements

• Clears stale success/error messages when a new file is selected
• Prevents overlapping or misleading states
• Keeps frontend behavior aligned with backend response semantics

---

Backend note (non-behavioral)

This PR does not introduce any new backend import logic, idempotency rules, or duplicate detection.

Duplicate-safe and idempotent behavior already exists in the backend and remains unchanged, including:

• cre_main.register_cre(...), which detects existing CREs and avoids re-creation
• cre_main.register_standard(...), which safely reuses existing standards and mappings
• Existing import flows where re-uploading the same data naturally results in:
  • new_cres = []
  • new_standards = 0

This PR does not attempt to reimplement or infer idempotency in the frontend.

Instead, the frontend strictly trusts and reflects backend outcomes.

A small, non-behavioral refinement was made in web_main.py to make these already-existing outcomes explicit in the API response (e.g. classifying a successful import as created vs noop).
This refinement does not change how imports are processed — it only makes the backend response more intention-revealing and predictable for frontend consumption.

In short:

• Idempotency and duplicate handling already existed → untouched
• Backend behavior remains the source of truth
• This PR only improves how those outcomes are communicated to users

---

Screenshots

1. Successful import (data created)

2. Empty CSV (no-op import)

Note on duplicate (idempotent) imports

Duplicate no-op imports (re-uploading the same CSV) cannot be reliably demonstrated in the local development environment because the database is ephemeral.

The UI behavior for this case is implemented based on backend response semantics and can be verified in an environment with a persisted database.

---

What is intentionally out of scope

• Backend import logic or idempotency rules

  Existing backend behavior already handles duplicates safely, including:

  • cre_main.register_cre(...) avoiding CRE re-creation
  • cre_main.register_standard(...) reusing existing standards and mappings
  • Import flows that correctly return:
    • new_cres = []
    • new_standards = 0

• Database-level duplicate handling

  No schema, constraints, or persistence mechanisms were modified.

This PR only improves how already-existing backend outcomes are communicated to users.

---

Why this matters

• Prevents users from assuming data was created when nothing changed
• Makes CSV imports safe and intuitive to retry
• Aligns UI feedback with real-world idempotent import behavior

---

Feedback welcome

If maintainers prefer different wording or severity (info vs success), I’m happy to iterate.