Introduce Reusable Mutation Abstraction with Centralized Toast Handling and Optional Optimistic UI

**Is your feature request related to a problem? Please describe.**

Currently, GraphQL mutations across the frontend define their own onCompleted, onError, and toast handling logic individually. This leads to:

1. Repeated toast configuration logic across multiple mutation hooks
2. Inconsistent error formatting (e.g., "Failed to assign issue: " + error.message)
3. Heavy reliance on refetchQueries with awaitRefetchQueries: true, which introduces additional network roundtrips
4. No support for optimistic UI updates
5. For example, in useIssueMutations, multiple mutations repeat similar success and error toast patterns:

```
onCompleted: () => {
addToast({ ... })
},
onError: (error) => {
addToast({ ... })
}
```
This duplication makes the codebase harder to maintain and scale as more mutations are added.

**Describe the solution you'd like**

1. Introduce a reusable abstraction (e.g., useAppMutation) that wraps Apollo’s useMutation and provides:
2. Centralized success toast handling
3. Centralized error toast handling
4. Optional integration with existing global error/Sentry logging
5. Support for optional optimistic UI updates
6. Refetch support only when explicitly needed

Example usage:

```
const [assignIssue] = useAppMutation(AssignIssueToUserDocument, {
successMessage: 'Issue assigned successfully',
errorMessage: 'Failed to assign issue',
optimisticUpdater: (cache, result) => {
// optional cache update logic
}
})
```
This would reduce duplication, improve consistency, and improve perceived performance.
**Describe alternatives you've considered**

Continuing with per-mutation onCompleted and onError handlers (current approach).

Introducing only centralized error handling without addressing optimistic UI.

However, a reusable abstraction provides both maintainability improvements and a foundation for performance enhancements.
**Are you going to work on implementing this?**

- [x] Yes
- [ ] No