Does SecItemDelete guarantee immediate invalidation of an already-retained Secure Enclave SecKeyRef on macOS?

I’m looking for the documented Security.framework/macOS contract for this exact same-process sequence.

1. An app creates a P-256 private key with SecKeyCreateRandomKey using:

   kSecAttrKeyType = kSecAttrKeyTypeECSECPrimeRandom
   kSecAttrKeySizeInBits = 256
   kSecAttrTokenID = kSecAttrTokenIDSecureEnclave
   

   and, within kSecPrivateKeyAttrs:

   kSecAttrIsPermanent = true
   kSecAttrApplicationTag = <a unique tag>
   

2. The app keeps the SecKeyRef returned directly by SecKeyCreateRandomKey alive and copies the corresponding public key with SecKeyCopyPublicKey.

3. The app calls SecItemDelete with a query that uniquely matches that exact keychain item, and SecItemDelete returns errSecSuccess.

4. Immediately after SecItemDelete returns, in the same process and without releasing or reacquiring the private-key reference, the app attempts a private-key operation using that same creation-returned SecKeyRef.

Does errSecSuccess contractually guarantee that the already-retained SecKeyRef can no longer perform private-key operations from the point SecItemDelete returns?

More concretely, is the following outcome forbidden by the API/platform contract: SecKeyCreateSignature succeeds after deletion, and the resulting signature verifies with the public key copied before deletion—that is, the public key from the same generated key pair?

Or is invalidation of an already-issued SecKeyRef unspecified or otherwise not guaranteed by Security.framework?

I’m asking only about the immediate post-return usability of the creation-returned SecKeyRef in this exact sequence. A clarification from Apple staff distinguishing the supported API/platform contract from current implementation behavior would be especially helpful.