[2.x] Fix notifications endpoint 400 on invalid subject.discussion default include

[karl-bullock]

Fixes #4815

Changes proposed in this pull request

NotificationResource added subject.discussion to the notifications endpoints' default include whenever more than one notification subject type was registered:

$this->initialized && count($this->subjectTypes()) > 1
    ? 'subject.discussion'
    : null,

That nested include is only valid when at least one subject type actually exposes an includable discussion relationship. The include validator validates default includes too, so when the subject collection is, for example, {discussions, users} (neither of which has a discussion relationship), it rejects the endpoint's own default include:

{"errors":[{"status":"400","code":"validation_error","title":"Bad Request","detail":"Invalid include [subject.discussion]","source":{"parameter":"include"}}]}

Because NotificationListState sends no explicit include and relies on the server default, this returns 400 for every user and breaks the notifications dropdown and page. User subjects are not exotic: flarum/mentions ships UserMentionedBlueprint; it only stays safe because it also ships PostMentionedBlueprint, and Post has a discussion relationship. Any forum with a User-subject (or Group-subject) notification type and no Post-subject type present hits this.

This PR gates the include on whether a subject type genuinely exposes an includable discussion relationship, instead of on the subject-type count. The include is preserved exactly where it matters (Post subjects) and dropped only when it would be invalid.

Reviewers should focus on

• subjectsHaveDiscussionRelationship() resolves each subject type's resource and checks its fields for an includable discussion relationship. This uses resolveFields() (which applies field extenders), guarded by an instanceof AbstractResource check.

Verified

Reproduced and fixed on a fresh 2.0.0-rc.5 install (MariaDB):

Registered subject types	GET /api/notifications before	after
{discussions} (core only)	200	200
{discussions, users}	400	200
{discussions, users, posts}	200	200

Two regression tests are added to notifications/ListTest: one asserting the endpoint no longer 400s when a subject type has no discussion relationship, and one asserting the discussion is still eager-loaded when a discussion-bearing subject type is present. The existing notification tests still pass.

[imorland]

Superseded by #4828, which combines this with #4817 and adds tests for both. Thanks!