Statement store: remove can hide a newer successful resubmission from QueryIndex

[DenzelPenzel]

Description of bug

A successful remove(hash) can apply a stale QueryIndex deletion after a newer successful resubmission of the same statement.

Store::remove updates SubmitIndex and commits the DB deletion while holding submit_index, then releases that lock before taking query_index:

• substrate/client/statement-store/src/lib.rs:1633-1653
• substrate/client/statement-store/src/lib.rs:1654-1657

This allows the following ordering:

1. S1 is active in SubmitIndex, DB, and QueryIndex.
2. remove(S1) removes it from SubmitIndex, commits the DB deletion, and releases submit_index.
3. Before remove acquires query_index, submit(S1, Local) observes the expired entry, successfully resubmits it, commits it to DB, inserts it into QueryIndex/recent, and notifies subscribers.
4. The older remove(S1) resumes and calls query_index.remove(S1), deleting the state installed by the newer successful submit.

Final state:

SubmitIndex contains S1: true
DB contains S1:          true
QueryIndex contains S1:  false
recent contains S1:      false

Consequently:

has_statement(S1) == false
statement(S1) == Some(S1)

Statement remains active and consumes account/global capacity, but is absent from topic queries, statement_hashes, historical/reconnected subscriptions, and recent propagation.

[s0me0ne-unkn0wn]

It'll be mostly solved in #12304, not consciously but by design: the body and index are written to disk as a single atomic commit. Still, the recent in-memory set remains vulnerable. IIUC, to fix that, it's enough to take the query index lock before releasing the submit index lock.