Add documentation

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

website/content/api-docs/secret/pki.mdx

@@ -2962,7 +2962,8 @@ $ curl \
 ```json
 {
   "data": {
-    "default": "3dc79a5a-7a6c-70e2-1123-94b88557ba12"
+    "default": "3dc79a5a-7a6c-70e2-1123-94b88557ba12",
+    "default_follows_latest_issuer": "false"
   }
 }
 ```
@@ -2982,6 +2983,27 @@ This endpoint allows setting the value of the default issuer.
   either a name or an ID). When no value is specified and the path is
   `/pki/root/replace`, the default value of `"next"` will be used.
 
+- `default_follows_latest_issuer` `(bool: false)` - Specifies whether a
+  root creation or an issuer import operation updates the default issuer
+  to the newly added issuer.
+
+  While the new multi-issuer functionality of 1.11 was backwards compatible
+  on a per-API basis, some applications relied explicitly on unsafe behavior
+  across multiple APIs that we addressed. For instance, calling
+  `/intermediate/generate/:type` would silently remove any (potentially
+  in-use!) key material and generate new private keys. While our response to
+  this endpoint is backwards compatible (returning a new key and safely
+  preserving old keys), some applications implicitly relied on this behavior.
+  This new option is meant to provide compatibility across API calls to these
+  callers: the newly created issuer (once _imported_ -- not on intermediate
+  generation) will become the default and it will look (to anyone strictly
+  using old APIs) that it is the only issuer in the mount. However, it is
+  encouraged for applications to update to the newer, safer semantics
+  associated with [multi-issuer rotation](/docs/secrets/pki/rotation-primitives).
+
+~> Note: When an import creates more than one new issuer with key material
+   known to this mount, no default update will occur.
+
 #### Sample Payload
 
 ```json