fix(identity): improve error handling and loading states for prodel

[hgw77]

Summary

Fix silent failure when deleting a project with child projects. The backend returns HTTP 403 with a clear error message, but the UI was not surfacing it to the user.

Changes Made

• Extract error message string in .catch() instead of storing the raw error object ( errorData?.error?.message || errorData?.message || ...)
• Move the error component outside the {data && !loading} block so it renders regardless of fetch state
• Replace the ternary data ? ... : <p>Loading...</p> with independent conditions so a fetch error does not show "Loading..." instead of the error
• Clear apiError at the start of each delete attempt (setApiError(null))
• Remove leftover console.log/console.error debug calls

Flow Diagram

  DELETE /os-api/prodel/api/v1/projects/:id
    │
    ▼
  OsApiController#reverse_proxy
    │
    └─ elektron → Prodel Backend
                    │
                    └─ HTTP 403
                       {"message": "Cannot delete the project since
                        it is not a leaf in the hierarchy..."}
    │
    ▼
  rescue → render json: { error: { message: "..." } }, status: 403
    │
    ▼
  ajax_helper.js  (response.ok === false → throw Error)
    error.data = { error: { message: "..." } }
    │
    ▼
  onConfirm() .catch()

    BEFORE                          AFTER
    ──────────────────────────      ──────────────────────────
    setApiError(error.data)         message = error.data?.error?.message
    ↓                               setApiError(message)
    {data && !loading ?             ↓
      <Message text={               {apiError &&
        apiError.error.message}/>     <Message text={apiError}/>}
    : <p>Loading...</p>}            ← always visible, independent of data
    ↑
    never rendered when data===null

Related Issues

• Issue: [Bug](prodel): Deletion of project with child projects doesn't surface backend error #2133

Checklist

• I have performed a self-review of my code.
• I have commented my code, particularly in hard-to-understand areas.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.
• I have made corresponding changes to the documentation (if applicable).
• My changes generate no new warnings or errors.