fix(ipsec-xfrm): reject missing-SA rekeys in MockXfrmBackend

[VerifiedOrganic]

Problem

LinuxXfrmBackend::rekey_sa issues XFRM_MSG_UPDSA. The upstream Linux handler routes that message to xfrm_state_update, which locates the existing SA and returns -ESRCH when the lookup misses. The SDK maps that authoritative miss to XfrmError::NotFound.

MockXfrmBackend::rekey_sa currently uses map insertion and returns Ok(()) even when no matching SA exists. It therefore creates state on an update-only operation and can false-green rekey behavior that the Linux backend rejects.

Required contract

• Build the existing-SA lookup using the same modeled Linux lookup identity as the mock SA store.
• If no matching SA exists, return XfrmError::NotFound without inserting or altering any SA.
• Operation capture may record the rejected rekey attempt, but stored state must remain unchanged.
• Preserve successful update behavior when the matching SA does exist.

Required tests

• Rekey an empty unscoped mock backend, assert NotFound, then query the identity and prove that no SA was inserted.
• Repeat with a nonzero if_id; the Linux SA lookup tuple still controls whether an existing SA is present, and a miss must not create one.
• Install an SA first, rekey the matching identity, and prove the intended existing-state update still succeeds.

The regression must exercise the public MockXfrmBackend.

[VerifiedOrganic]

Implementation is in progress in the existing isolated #409/#416 XFRM worktree because this is another MockXfrmBackend parity invariant in the same safety boundary. The combined candidate will make rekey update-only against the modeled Linux lookup identity, preserve state on authoritative misses, and cover missing and existing SA cases through the public backend before independent review. No separate overlapping branch will be opened.

[VerifiedOrganic]

Adversarial review: successful rekey does not preserve Linux if_id update semantics

The missing-SA repair now locates an existing mock SA through the modeled Linux core and masked-mark lookup. The successful-update path then rebuilds the stored relocation identity from the new request and assigns only the old lookup mark. That makes an unscoped rekey request clear a nonzero stored if_id in MockXfrmBackend.

Linux xfrm_state_update behaves differently for an existing valid state: it assigns x1->if_id = x->if_id only when the new x->if_id is nonzero. Therefore:

• existing nonzero if_id plus a rekey request with if_id: None preserves the existing value;
• existing None plus a nonzero request sets the new value;
• existing nonzero plus a different nonzero request replaces it with the new value.

Please preserve that behavior in the Mock successful-update path and add public-backend regressions for all three cases. Each test should install the original SA, rekey through the public trait method, query the exact resulting identity, and prove there is still exactly one SA under the Linux lookup tuple. Keep operation capture unchanged.

This does not block the ePDG's initial unscoped SWu call path, where the checked-in initial SA intents use if_id: None; it is a Mock/Linux parity requirement for scoped rekey coverage.