fix: make kstorage write_kstorage find+replace atomic

[AYwlilwYA]

Problem

write_kstorage() had a race between finding an existing entry and replacing
it:

rcu_read_lock();
hlist_for_each_entry_rcu(pos, bucket, hnode) {  // lookup OUTSIDE the lock
    if (pos->did == did) { old = pos; break; }
}
spin_lock(lock);
if (old) {
    hlist_replace_rcu(&old->hnode, &new->hnode);  // replace INSIDE the lock
}

Two writers racing on the same did could both find the same old node.
The first thread replaces it (old->pprev becomes LIST_POISON2); the second
thread then calls hlist_replace_rcu() on the already-replaced node and
WRITE_ONCE(*old->pprev, new) writes through the poisoned pointer
(dead000000000122), causing a kernel Oops.

Observed in the field: apd (APatch daemon) crashed with
Unable to handle kernel paging request at virtual address dead000000000122
(LIST_POISON2) during APatch re-authorization after a system_server soft
restart, exactly at hlist_replace_rcu()'s old->pprev = LIST_POISON2.

Fix

Move the lookup inside the group spinlock so find + replace/add are atomic
under the same lock. remove_kstorage() already does its find+del under the
lock and is unaffected.

Verified: kstorage.c compiles cleanly (aarch64, no new warnings).

[Admirepowered]

kstorage在什么情况下会导致这样的情况，自旋锁会导致大量写入被拦截排队。正常使用不会触发到