fix(pki): add per-order lock and processing status to ACME order finalize

[goingforstudying-ctrl]

I ran into GH-31987 while reading through the PKI ACME handler — two concurrent finalize requests on the same order can both pass the readiness gate and both issue distinct certificates, but the order can only track one serial number, so the other cert is orphaned from all order-keyed lookups.

The root cause is that acmeFinalizeOrderHandler does a plain Storage.Get → status check → issue → Storage.Put with no serialization between the read and the write.

This PR adds two layers of protection:

1. Per-order striped lock (locksutil) around the entire handler body. This serializes concurrent finalize calls for the same order ID so only one can enter the critical section at a time.

2. Intermediate "processing" status as defense-in-depth. After the lock is acquired and validations pass, the order is immediately saved with ACMEOrderProcessing status before any certificate is issued. If a second request somehow reaches the handler despite the lock (e.g. across cluster nodes on different lock stripes), the order.Status != ACMEOrderReady gate will reject it with ErrOrderNotReady.

The computeOrderStatus helper already treats ACMEOrderProcessing as a non-terminal status, so the intermediate save doesn't change the authorization-recheck behavior for any codepath that recomputes status after the fact.

I went with locksutil over a plain sync.Mutex map because it's the idiomatic pattern in this codebase (used by the database backend, approle, cert auth, and others). Downside is the 256-stripe hash means two different order IDs will occasionally contend on the same underlying RWMutex, but in practice the critical section is brief — just the CSR parsing + cert issuance — and the processing-status gate ensures correctness even when the lock doesn't perfectly isolate.

Not sure about the AcmeAccountStatusValid constant I used in the test setup — I picked it from the existing account status values, but let me know if there's a better constant for "active account" in test contexts.

Closes #31987

[vercel]

@goingforstudying-ctrl is attempting to deploy a commit to the HashiCorp Team on Vercel.

A member of the Team first needs to authorize it.

[hashicorp-cla-app]

All committers have signed the CLA.

[vercel]

Deployment failed with the following error:

The `vercel.json` schema validation failed with the following message: should NOT have additional property `public`

Learn More: https://vercel.com/docs/concepts/projects/project-configuration

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
vault-ui	Error		Jul 2, 2026 8:36pm