fix(notifications): stop the severity filter from eating approval events

[0xmanhnv]

All three approval_* notifications are undeliverable on a default configuration. A finding awaiting a decision blocks forever and nobody is told.

Two gates, and the second silently defeats the first

ShouldNotifyEventType   empty enabled_event_types -> platform defaults
ShouldNotify            empty enabled_severities  -> critical + high ONLY

DefaultEnabledEventTypes() deliberately turns EventTypeApprovalRequested on, with the reasoning recorded right next to it:

"An approval request is addressed to a human; if it reaches nobody the finding stays blocked indefinitely. The approved/rejected outcomes are deliberately NOT default-on..."

The enqueue sites then stamp a constant severity:

event	severity	site	survives default filter?
approval_requested	medium	vulnerability_service.go:2355	no
approval_rejected	medium	vulnerability_service.go:2542	no
approval_approved	low	vulnerability_service.go:2458	no

Someone opened the event-type gate on purpose; the severity gate closed it again. The exact outcome that comment exists to prevent is what happens today.

I swept every enqueue site to check whether this was wider — it is not. sla_breach (high) and finding_priority_escalated (mapped from priority class) survive; new_finding / new_exposure / finding_assigned pass the real finding severity, which is correct. The approval trio is the whole of it.

Why not just bump the constants to "high"

Because that launders a workflow event through a field that does not apply to it, and the next person reading Severity: "high" on an approval request would reasonably conclude a high-severity finding was involved.

The actual root cause is that EnqueueParams.Severity carries two different things:

• For finding-shaped events it is the finding severity. An operator leaving the filter at its default is saying "only critical and high findings" — honoring that is the entire point of the filter.
• For approval lifecycle events it is a constant picked by the enqueue site. It describes no finding, and no operator ever asked to suppress it.

So SeverityFilterApplies(EventType) decides per event type whether the severity gate is meaningful. The approval trio is exempt and remains fully controllable through the event-type filter — the switch that actually means "I do not want these".

SendNotificationInput gains EventType so the single-integration path makes the same decision as the broadcast path. Empty is treated as filterable, so every existing caller keeps its current behavior.

Completeness gate

A new event type must now be classified as severity-bearing or not, or the build fails naming it:

event type "sla_breach" is not classified. Decide whether its EnqueueParams.Severity
is a real finding severity (add it to `filterable`) or a constant picked by the enqueue
site (add it to `notFilterable` AND to SeverityFilterApplies). Inheriting the default
silently is how approval_requested became undeliverable.

Verified to fire, not just present — I removed one classification and confirmed it fails and names the offender, then restored it. Inheriting the default silently is exactly how this bug happened.

Verification

• New tests pin both halves together: the event-type gate passes AND the severity gate no longer drops it, on an empty (default) config. The test asserts up front that "medium" really is excluded by the default severity set, so it cannot pass vacuously.
• The filter still applies to new_finding, new_exposure, finding_assigned, finding_priority_escalated, sla_breach — a fix that delivers everything is not a fix.
• GOWORK=off go build ./... — ok
• GOWORK=off go test ./... against app_test — all green
• GOWORK=off make lint-ci — clean

Not verified end-to-end: there are no integration_notification_extensions rows on the live database, so I could not observe a real Slack/Teams delivery. This is proven at the domain + dispatch layer, not against a live channel.