Account remove leaves a key admitted when a link moved a local row onto it #3210

What

On main, an account remove for key K can leave K admitted on a PC when a row there had its key moved onto K by a link.

removeAccountKey (server/devices.ts) leaves a row alone when it has no added_by and its created_at is after the remove's issued_at: that rule is meant for a pairing made on this PC after the removal was signed. But linkAccountKey changes a row's key in place and keeps created_at and the missing added_by, so a row that was paired as key X and later linked onto K passes the same test, although K itself was never paired on this PC.

Trace

1. Member A signs remove for K (for example a stolen key). The account service holds it back from PC P.
2. On P, a device is paired locally with key X, after A signed the removal (created_at > issued_at, no added_by).
3. That device's session sends a link moving its row from X to K (old_key X, key K).
4. A's removal of K reaches P: removeAccountKey sees a row with key K, no added_by and created_at after issued_at, answers unchanged, and K stays admitted on P.

Found by a Codex adversarial review on #3208 (traced, not reproduced on a running PC). The same path also makes a client's removal report call such a row "paired again"; #3208 now asks the PC for paired_here (rows paired locally and never moved by a link) and labels that case "could not confirm" instead.

Plan

Handled in the follow-up branch fix/account-settle-old-removes (PC-side): a row a link moved onto a key (linked_at set) is not a pairing of that key on this PC, so the removal applies. A failing-first contract test goes with it. That branch also settles an old remove from a former member instead of keeping it waiting forever.