UI silently ignores 403 errors on push approve/reject actions

[fabiovincenzi]

Describe the bug
When a user without canAuthorise permission attempts to approve or reject a push via the admin UI dashboard, the server correctly returns 403 Forbidden. However, the UI silently ignores the error and navigates the user back to the push list as if the action succeeded. No error message or feedback is shown.

To Reproduce

1. Login as a user with canPush permission but without canAuthorise permission
2. Go to /dashboard/push and click on a pending push
3. Click "Approve", check the attestation checkboxes, and click "Approve" to confirm (or click "Reject")
4. The user is navigated back to the push list without any error message
5. The push remains in "Pending" state — the action silently failed

Expected behavior
A snackbar error message should inform the user that they lack permission to approve/reject the push (e.g. "You are not authorised to approve this push"). The user should remain on the push detail page.

Root cause

authorisePush and rejectPush in src/ui/services/git-push.ts only handle 401 (not authenticated) responses. 403 (not authorized) is silently swallowed in the .catch() block:

// src/ui/services/git-push.ts - authorisePush (line 88-92)
.catch((error) => {
  if (error.response && error.response.status === 401) { // only 401, not 403
    errorMsg = 'You are not authorised to approve...';
    isUserAllowedToApprove = false;
  }
});

The same pattern exists in rejectPush (lines 107-111).

The server-side correctly returns 403 in these cases (src/service/routes/push.ts):

• "Cannot approve/reject your own changes" (self-approval)
• "User not authorised to approve/reject" (missing canAuthorise permission)

Additional context
Discovered during implementation of e2e tests for #1390. The negative test cases document this behavior with TODO comments in cypress/e2e/pushActions.cy.js.

[kriswest]

Could we expand this issue to also cover the fact that, if the user is not logged in, the UI delivers the wrong error message?
Specifically it reports:

You are not authorised to reject...

Which would be the error message that needs to be delivered if you are in fact logged in but not authorized.

Its possible that this was caused when we corrected the response codes in the API - but I suspect its been around longer than that. A single PR should address both problems by delivering the error message on 403 and redirecting the user to the login form on 401.

n.b. Approve displays the authorise form before hitting the API - but I can live with that. However, we could be visibly disabling all 3 buttons if the user is not logged in.

Cancel behaves slightly differently to both Approve and Reject but needs the same handling applied.