I see two possible solutions.

a) Call the verify status handler before the decrypt status handler.
This could obviously cause other problems, e.g. if the verify status handler returns an error on GPGME_STATUS_EOF (which can happen if a status error was detected previously, or, highly unlikely, if a memory allocation failed) then the finalization of the decryption result will be skipped.

b) Call the verify status handler on GPGME_STATUS_EOF even if the decrypt status handler returned an error, i.e.

@@ -35,13 +35,15 @@ decrypt_verify_status_handler (void *priv, gpgme_status_code_t code,
 			       char *args)
 {
   gpgme_error_t err;
+  gpgme_error_t err2;
 
   err = _gpgme_progress_status_handler (priv, code, args);
   if (!err)
     err = _gpgme_decrypt_status_handler (priv, code, args);
-  if (!err)
-      err = _gpgme_verify_status_handler (priv, code, args);
-  return err;
+  /* allow handling of EOF even if previous handler returned an error */
+  if (!err || code == GPGME_STATUS_EOF)
+    err2 = _gpgme_verify_status_handler (priv, code, args);
+  return err ? err : err2;
 }

I think I prefer solution b) because it avoids the unforeseen side effects of changing the order of the two calls. In particular, it avoids introducing the same problem for the decryption result that we are trying to fix for the verification result.

P.S.
c) The least hacky solution would probably be a combined decrypt_verify_status_handler. But that would likely add a lot of duplicate code and would break the clean separation of decryption and verification.

I have some doubts that signed-only archives are very useful. The only use case is that this allows to sign stuff without saving it first. You would need to do this in my generally preferred detach signature case.

You solution b) seems to be best. Could we easily do this only in archive mode to avoid any risk of regression?