chose(docs): Add storage tip to store key last digits

docs/pages/design/next/index.md

@@ -41,6 +41,7 @@ Clerk could expose a similar (or even the same - dogfooding) UI component as in
 - Depending on the key format (and this is related with the API implementation as well) then keys might be easier to select - it is easier to select the API key in snake case:
   - `4a8b93d2-7f82-46f8-a8b1-88f2a5d67254`
   - `b7e23eeb44b34185bcf657e5c88df016_24d4b6`
+- Show the token's last few digits in the UI to help users manage keys effectively.
 
 ### UI utilities
 

docs/pages/design/node/index.md

@@ -98,6 +98,8 @@ The `Auth` object should contain an identifier for the non-user principal making
 
 #### Storage
 
+Store the hash of a key and consider saving the last few digits of your key for reference. This helps customers identify which key they want to revoke, change scopes for, etc.
+
 API-key storage implementations is divided into two groups: **Retrievable** and **Irretrievable**. Each have their security tradeoffs.
 
 **Irretrievable:**
@@ -142,3 +144,5 @@ That checksum can also be a signed hash. The signing authority can be confident
 Requests to manage keys should be as fast as possible. An in-memory cache can be used to store keys in order to perform a database roundtrip on every single read.
 
 For security, it's recommended to perform caching only hashed key versions and perform pre-hash collision checks during key creation to avoid collisions.
+
+Also, verify incoming API tokens early in an HTTP request's lifecycle.