Team Recipients for Notifications (email + ACL scope)

### Current Behavior

Notification rules currently target publishers with static destinations (email address). When a portfolio-scoped event occurs (such as a policy violation), Dependency-Track generates a notification containing the impacted project based on the rule’s project/tag filters, but it does not apply the recipient team’s ACL to that notification payload.

As a result, a team can receive policy notification emails that reference projects outside of its ACL scope, including projects owned by another team.

### Steps to Reproduce

1. **Create two teams**
- `Team A`
- `Team B`

2. **Create two projects**
- `Project A`
- `Project B`

3. **Configure ACLs so teams are isolated**
- Grant **Team A** access **only** to `Project A`.
- Grant **Team B** access **only** to `Project B`.

4. **Create a policy that will be violated**
- Make sure this policy applies to all projects

5. **Create a Notification Rule for policy violations**
- Scope: **PORTFOLIO**
- Notify on: **Policy Violation**
- Publisher: **EmailPublisher**
- Destination: email address for **Team A**
- limit the rule to projects `Project A` and `Project B`

6. **Trigger a policy violation on Project B**
- Upload a BOM to `Project B` containing a component that violates the policy.
- Wait for BOM processing to complete and the violation to be detected.

7. **Observe the notification email**
- The email sent to **Team A** includes `Project B` (and related violation details),
even though Team A has **no ACL access** to Project B.

### Expected Behavior

When a notification rule triggers, Dependency-Track should deliver notifications that respect organizational access boundaries:

- **Recipient-aware filtering of projects**:
Before sending, Dependency-Track should filter the notification payload to keep only projects the recipient is allowed to see.
For a team recipient, this means:
`Notification.projects = affected projects ∩ team.allowedProjects`.

- **No cross-team notifications**:
A team must never receive a policy notification referencing projects outside its ACL scope, even if the underlying policy/rule matched those projects globally.

- **Skip notifications with no visible projects**:
If filtering leaves zero projects, the notification should not be sent to that team.

**Proposed fix**

Instead of configuring a static destination email in the notification rule, the rule should allow selecting a **Team as the recipient**. Dependency-Track would then:

1. **Resolve the destination from the Team**
Use the Team’s configured email automatically, removing the need to hardcode an email address in the rule.

2. **Apply the Team’s ACL to the notification payload**
Filter `Notification.projects` using the Team’s `allowedProjects` before rendering and publishing.

This makes notifications correct by design: the recipient identity (Team) carries both the destination and the authorized scope, so notifications cannot leak projects across teams and configuration remains centralized in one place.

### Dependency-Track Version

4.13.6

### Dependency-Track Distribution

Container Image

### Database Server

PostgreSQL

### Database Server Version

_No response_

### Browser

Google Chrome

### Checklist

- [x] I have read and understand the [contributing guidelines](https://github.com/DependencyTrack/dependency-track/blob/master/CONTRIBUTING.md#filing-issues)
- [x] I have checked the [existing issues](https://github.com/DependencyTrack/dependency-track/issues) for whether this defect was already reported