Do contentious Firestore Transactions invoked from Firebase Functions lock+wait or retry?

Question

The Firestore Documentation states that for "server client libraries":

When a transaction locks a document, other write operations must wait for the transaction to release its lock. Transactions acquire their locks in chronological order.

But for "mobile/web SDKS":

The transaction completes its write operations only if none of those documents changed during the transaction's execution. If any document did change, the transaction handler retries the transaction.

The documentation states are two models: lock + wait (server) and retry (client). However, when I run my Firebase Function that is purposely designed to cause contention, I find that Firebase Functions is using retry rather than lock + wait:

let count = 0; //DEBUG ONLY
return admin.firestore().runTransaction(async (transaction: Transaction) => {
  if (count > 0) {
    console.log("Contention Retry: " + count);
  }
  count++; //DEBUG ONLY 
  doc = await transaction.get(docRef); //Read
  await transaction.set(docRef, doc.data(), setOptions); //Write
});

When contention occurs, I see the "count" increasing as Firebase retries the transaction due to contention.

Are Firebase Functions supposed trigger the retry transactions model with Firestore? Why does the documentation say it uses lock+wait? Is there any way to actually force Firestore to use lock+wait instead? Would using the Firestore SDK rather than Firebase Admin SDK make a difference?

Thanks in advance.

EDIT: Not the same as: How to retry a Cloud Firestore transaction in a Cloud Function until state == true which is asking about automatic retry without a read/write. My question was whether the read would be blocked if another process was in a transaction and read the same document.