fix(feat:client-identifiers): fix dialog visibility issues for creating client identifiers

[sam-arth07]

Fixes - MIFOSAC-498

Changes made in the PR:

• Refactored dialog visibility logic for creating client identifiers:

  • The previous implementation managed the show/hide state of the create identifier dialog directly in the UI layer, leading to inconsistent UI behavior. The logic was moved into the ViewModel, ensuring dialog state is now driven by a single source of truth and tied to UI state updates.

• Standardized success/error feedback: show toast on successful identifier creation and error UI on failures, all driven by a single sealed UI state and SharedFlow events.

• Issue: Delete Identifier flow showed Loading twice;

  • Fix: Ensure a single collection per delete action and emit Loading once before the repository call; removed redundant state updates that caused duplicate emissions.
    Screenshots

• Issue: Pull-to-refresh didn’t trigger loading on main screen; data refreshed silently.

  • Fix: Updated refreshIdentifiers in the ViewModel to explicitly set/loading/reset refresh state and emit a Loading UI state; UI now binds rememberPullRefreshState to the ViewModel’s refreshing flag.

---

Testing notes

• Create: Open Create Identifier, submit valid data → dialog dismisses, screen enters loading, success toast shows, list refreshes.
• Delete: Delete an identifier → only one loading transition, no duplicate spinners.
• Pull-to-refresh: Swipe down → screen enters loading, refresh indicator shows, content updates, indicator stops.

---

Before:

---

before.mp4

---

After:

finalSol.mp4

---

Please make sure these boxes are checked before submitting your pull request - thanks!

• Run the static analysis check ./gradlew check or ci-prepush.sh to make sure you didn't break anything

• If you have multiple commits please combine them into one commit by squashing them.

[itsPronay]

Target branch is kmp-impl, are we planning to merge this before the kmp-impl merging PR?

[biplab1]

@sam-arth07 There seems to be two consecutive loading states — one in the dialog and another in the main screen after a successful submission. (see video at 13-15 seconds)

[biplab1]

@sam-arth07 The expected behavior is that the dialog should close immediately after submission (without showing any loading), and the loading indicator should appear only on the main screen while fetching the updated list. Currently, the opposite is happening: the dialog shows the loading state, while the main screen does not.

[biplab1]

Please update the PR description with all the changes made, and fix the one minor change requested below. The rest looks good to me, and this can be merged.

[therajanmaurya]

Closing in response of #2450