[2.x] fix: Stop a realtime update duplicating a discussion in the list - #4993

Changes proposed in this pull request:

DiscussionListState adds and removes discussions by matching on the model instance (indexOf). Realtime hands the list a discussion resolved through app.store.pushPayload, and the store returns a fresh instance whenever it no longer holds the one already on screen — a discussion that has scrolled out of the loaded pages, for instance. The reference match then fails to find the copy in the list, so addDiscussion adds the discussion a second time, and it shows twice until the page is refreshed. (Reported against rc.7: "left the tab idle, came back to a duplicate discussion; refreshing fixes it.")

• deleteDiscussion now matches by discussion.id() rather than object reference, so a fresh instance of a discussion already listed replaces it instead of duplicating it.
• It also fixes this.extraDiscussions.splice(index) — missing its length argument, it removed the matched item and everything after it — to splice(index, 1).
• A null id is guarded, so an unsaved discussion (should one ever reach the list) can't match another by null === null.

A note on forums without realtime: addDiscussion has no caller in core or any bundled extension — only realtime adds discussions to the list this way — so a non-realtime forum never hits the duplicate path at all. Its only route through this code is discussion deletion (PostControls, DiscussionControls), which passes the canonical list instance; there the id match and the old reference match are equivalent, so behaviour is unchanged.

Reviewers should focus on:

• That matching by id is safe here — the list only ever holds saved discussions (pages come from the API; extraDiscussions only ever receives store-resolved discussions), so ids are present and unique.
• That the splice(index) → splice(index, 1) change is correct — the old form was removing a tail of the pending list.

Necessity

• Has the problem that is being solved here been clearly explained? — a realtime update can show a discussion twice until refresh.
• If applicable, have various options for solving this problem been considered? — matching by id reuses the identity the store already keys on; tracking instances some other way would be heavier and no more correct.
• For core PRs, does this need to be in core, or could it be in an extension? — the list state lives in core; realtime and other extensions build on it.
• Are we willing to maintain this for years / potentially forever?

Confirmed

• Frontend changes: tested on a local Flarum installation. — reproduced the duplicate and its fix in a unit test (a fresh store instance of a listed discussion); the realtime path drives exactly this.
• Frontend changes: tests are green.
• Frontend changes: tests have been added. — covers, with realtime, re-adding the same and a fresh instance (no duplicate) and that the re-add moves to the top; and, without realtime, that removal drops the discussion and doesn't take the rest of the list with it.
• Backend changes: tests are green — no backend changes.
• Backend changes: tests have been added, or are not appropriate here — n/a.
• Where applicable, changes are suitable for all supported database drivers (MySQL, MariaDB, PostgreSQL, SQLite). — no database involvement.
• The description above is written by me and describes what this pull request actually does.

Required changes:

• Related documentation PR: (Remove if irrelevant)