[2.x] fix: notification dedup query never matches non-null data on MySQL

[imorland]

Summary

Fixes #4643. `Notification::scopeMatchingBlueprint()` on MySQL never matches existing rows when the blueprint's `data` is non-null, silently disabling dedup for every notification type whose blueprint returns non-null `getData()` — `postMentioned`, `newPost`, `postMoved`, plus extension types like `byobuPrivateDiscussionReplied`. Every edit of a post that triggered such a notification creates a new row and re-sends the email.

Root cause

Before:

```php
return $query->where($attributes)
->whenPgSql(function ($query) use ($data) {
return $query->whereRaw('data::text = ?', [$data]);
}, function ($query) use ($data) {
return $query->where('data', $data);
});
```

The PostgreSQL branch correctly casts the column to text. The else branch (MySQL / MariaDB / SQLite) compares the JSON column directly to a string. `getBlueprintAttributes()` produces `$data` via `json_encode($data)` — compact form like `{"replyNumber":58}`. MySQL stores its JSON column canonicalised — with a space after the colon: `{"replyNumber": 58}`. Direct string comparison never matches.

Fix

Branch by driver explicitly:

• PostgreSQL — cast column to text (`data::text = ?`). Unchanged.
• MySQL — cast parameter to JSON (`data = CAST(? AS JSON)`) so the comparison round-trips through MySQL's canonical form.
• MariaDB — its JSON type is just LONGTEXT and `CAST(... AS JSON)` isn't supported syntax. The bytes round-trip and plain string equality works.
• SQLite — JSON stored as plain TEXT, byte-for-byte round-trip, plain string equality works.

The null-data path is pulled out front since `= NULL` doesn't match anything on any engine.

Tests

Three integration tests in `framework/core/tests/integration/notification/MatchingBlueprintTest.php`:

1. `matchingBlueprint()` finds existing rows when blueprint data is null (sanity check).
2. `matchingBlueprint()` finds existing rows when blueprint data is non-null (the regression).
3. `NotificationSyncer::sync()` called repeatedly with the same blueprint+recipient produces exactly one row, not duplicates (the user-visible symptom).

The first commit added these tests without the fix, so the CI matrix demonstrated which engines were affected (MySQL fail; PostgreSQL/MariaDB/SQLite pass — confirming the diagnosis). The second commit applied the fix; full matrix now green.

Scale

From the issue reporter's production instance:

```
type dup_groups total_dup_rows
postMentioned 665 1,477
newPost 2 4
```

`postMentioned` is the dominant offender precisely because it has non-null data and the dedup query was broken for it.

Relationship to #4622

#4622 describes a queue-timing race in `NotificationSyncer::sync()` for null-data blueprints (where the dedup query does work, so duplicates only arise from a narrow window). For non-null-data blueprints, this bug means duplicates were guaranteed on every edit regardless of timing — much higher impact, much simpler fix. Both are needed; this is the one users hit most often.