Feat/default notification channels

[the-last-php-bender]

Describe your changes

Briefly describe the changes you made and their purpose.

This PR implements the ability to bulk-assign Notification Channels to Alerts as requested in issue #3601. The implementation includes:

1. Default Channel: Added the ability to mark a notification channel as 'Default' so it is automatically attached to any new monitor created.
2. Bulk Edit Mode: Added checkbox selection on the Uptime and Infrastructure monitor lists to "Add Notification Channel" or "Remove Notification Channel" to all selected items.
3. Global Defaults (Apply to All): Added an "Apply to All" button in the notification edit form that applies the notification channel to all existing monitors in the team.

Backend changes:

• Added isDefault field to Notification model
• Added API endpoints: GET /notifications/defaults, PATCH /notifications/:id/default, POST /notifications/:id/apply-to-all
• Added PATCH /monitors/notifications endpoint for bulk add/remove operations
  Frontend changes:
• Added "Default channel" toggle in notification creation/edit form
• Added bulk notification actions (Add/Remove) in Uptime and Infrastructure monitor pages
• Added "Apply to All" button in notification edit form
• Auto-attaches default notifications to new monitors

Write your issue number after "Fixes "

Fixes #3601

Please ensure all items are checked off before requesting a review. "Checked off" means you need to add an "x" character between brackets so they turn into checkmarks.

• (Do not skip this or your PR will be closed) I deployed the application locally.
• (Do not skip this or your PR will be closed) I have performed a self-reviewing and testing of my code.
• I have included the issue # in the PR.
• I have added i18n support to visible strings (instead of <div>Add</div>, use):

const { t } = useTranslation();
<div>{t('add')}</div>

• I have not included any files that are not related to my pull request, including package-lock and package-json if dependencies have not changed
• I didn't use any hardcoded values (otherwise it will not scale, and will make it difficult to maintain consistency across the application).
• I made sure font sizes, color choices etc are all referenced from the theme. I don't have any hardcoded dimensions.
• My PR is granular and targeted to one specific feature.
• I ran npm run format in server and client directories, which automatically formats your code.
• I took a screenshot or a video and attached to this PR if there is a UI change.

[Br0wnHammer]

Hi @the-last-php-bender, Thanks a lot for taking the time to contribute to the project. That said, the maintainers are working with limited bandwidth, and a diff this large takes a lot of context to review thoroughly. Would you be able to break this into a few smaller, focused PRs (or trim the scope)?

[the-last-php-bender]

Ok

[Br0wnHammer]

Hi @the-last-php-bender any update?

[the-last-php-bender]

Hi @the-last-php-bender any update?

I will be dropping updating on it soon splitting it is kinda a Hassel because the feature is dependent on each other

[Br0wnHammer]

@the-last-php-bender I would recommend to close this PR and create a new one, since we have refactored a lot of the server codebase, so there are a lot of moving pieces.

[the-last-php-bender]

@the-last-php-bender I would recommend to close this PR and create a new one, since we have refactored a lot of the server codebase, so there are a lot of moving pieces.

Okay but I will have to pull a d it might break what I have worked on or what do you think?

[Br0wnHammer]

@the-last-php-bender pull the latest changes, get your codebase up to date with our develop branch, and then start with the implementation with a more focused approach.

[the-last-php-bender]

@the-last-php-bender pull the latest changes, get your codebase up to date with our develop branch, and then start with the implementation with a more focused approach.

Ok thanks