Fix vale errors in Security Authentication mechanisms

extensions/security-webauthn/runtime/src/main/java/io/quarkus/security/webauthn/WebAuthnRunTimeConfig.java

@@ -213,14 +213,14 @@ public static class RelyingPartyConfig {
      * referred to as "renewal-timeout".
      *
      * Note that smaller values will result in slightly more server load (as new encrypted cookies will be
-     * generated more often), however larger values affect the inactivity timeout as the timeout is set
+     * generated more often); however, larger values affect the inactivity timeout because the timeout is set
      * when a cookie is generated.
      *
-     * For example if this is set to 10 minutes, and the inactivity timeout is 30m, if a users last request
-     * is when the cookie is 9m old then the actual timeout will happen 21m after the last request, as the timeout
+     * For example if this is set to 10 minutes, and the inactivity timeout is 30m, if a user's last request
+     * is when the cookie is 9m old then the actual timeout will happen 21m after the last request because the timeout
      * is only refreshed when a new cookie is generated.
      *
-     * In other words, no timeout is tracked on the server side; the timestamp is encoded and encrypted in the cookie
+     * That is, no timeout is tracked on the server side; the timestamp is encoded and encrypted in the cookie
      * itself, and it is decrypted and parsed with each request.
      */
     @ConfigItem(defaultValue = "PT1M")

extensions/vertx-http/runtime/src/main/java/io/quarkus/vertx/http/runtime/FormAuthRuntimeConfig.java

@@ -65,7 +65,7 @@ public enum CookieSameSite {
 
     /**
      * Option to control the name of the cookie used to redirect the user back
-     * to where he wants to get access to.
+     * to the location they want to access.
      */
     @ConfigItem(defaultValue = "quarkus-redirect-location")
     public String locationCookie;
@@ -83,15 +83,15 @@ public enum CookieSameSite {
      * referred to as "renewal-timeout".
      *
      * Note that smaller values will result in slightly more server load (as new encrypted cookies will be
-     * generated more often), however larger values affect the inactivity timeout as the timeout is set
+     * generated more often); however, larger values affect the inactivity timeout because the timeout is set
      * when a cookie is generated.
      *
-     * For example if this is set to 10 minutes, and the inactivity timeout is 30m, if a users last request
-     * is when the cookie is 9m old then the actual timeout will happen 21m after the last request, as the timeout
+     * For example if this is set to 10 minutes, and the inactivity timeout is 30m, if a user's last request
+     * is when the cookie is 9m old then the actual timeout will happen 21m after the last request because the timeout
      * is only refreshed when a new cookie is generated.
      *
-     * In other words no timeout is tracked on the server side; the timestamp is encoded and encrypted in the cookie itself,
-     * and it is decrypted and parsed with each request.
+     * That is, no timeout is tracked on the server side; the timestamp is encoded and encrypted in the cookie
+     * itself, and it is decrypted and parsed with each request.
      */
     @ConfigItem(defaultValue = "PT1M")
     public Duration newCookieInterval;