Add controls to "how clerk works" videos (#1812)

docs/how-clerk-works/overview.mdx

@@ -80,6 +80,7 @@ A user's process of signing in would work as follows. This example assumes that
      muted
      loop
      playsInline
+     controls
    />
 1. The next time the browser sends a request to the server, it [automatically includes](/docs/how-clerk-works/cookies) the session cookie. The server checks the database for the session ID and retrieves the associated user ID and session metadata. If the session is valid and active, the server has verified that the user has authenticated, and can then use the user ID to fetch any required user data and process the request.
    <Video
@@ -90,6 +91,7 @@ A user's process of signing in would work as follows. This example assumes that
      muted
      loop
      playsInline
+     controls
    />
 
 > [!NOTE]
@@ -114,6 +116,7 @@ The stateless authentication flow operates as follows. This example assumes that
      muted
      loop
      playsInline
+     controls
    />
 1. The next time the browser sends a request to the server, it sends the cookie containing the token. The server verifies the signature of the token to ensure that it's valid, and then uses the user ID within the token to fetch any required user data and process the request.
    <Video
@@ -124,6 +127,7 @@ The stateless authentication flow operates as follows. This example assumes that
      muted
      loop
      playsInline
+     controls
    />
 
 While more complex to implement, this stateless model offers significant advantages. Because verifying the JWT doesn't require interacting with a database, the latency overhead and scaling challenges caused by database lookups are eliminated, leading to faster request processing.
@@ -184,6 +188,7 @@ This example assumes that the user already signed up and their credentials are s
      muted
      loop
      playsInline
+     controls
    />
 1. And just like stateless auth, the next time the browser sends a request to the server, it sends the cookie containing the token. The server verifies the signature of the token to ensure that it's valid, and then uses the user ID within the token to fetch any required user data and process the request.
    <Video
@@ -194,6 +199,7 @@ This example assumes that the user already signed up and their credentials are s
      muted
      loop
      playsInline
+     controls
    />
 
 So far, this is the same as stateless auth, with one key distinction: the session token's expiration time. This is because normally, in stateless authentication implementations, the token's expiration is set to match the intended session duration - commonly ranging from one week to one month. But since JWTs can't be revoked, if a token is compromised, the attacker has the entirety of the session lifetime to be able to take over the user's account. This will be several days at least on average, if not several weeks.