chore: sync content to repo (#10174)

Co-authored-by: nilbuild <4921183+nilbuild@users.noreply.github.com>

src/data/roadmaps/api-design/content/filtering-sorting--search@dL3YellfAszBeJnm8KEYE.md

@@ -1,6 +1,6 @@
 # Filtering, Sorting & Search
 
-Filtering, sorting, and search are query capabilities that let API consumers retrieve exactly the data they need rather than fetching everything and processing it client-side. Filtering narrows results by field values (?status=active), sorting orders them (?sort=created_at&order=desc), and search allows freetext or fuzzy matching across fields. Designing these using predictable query parameter names and clearly documenting supported combinations is a significant part of API usability.
+Filtering, sorting, and search are query capabilities that let API consumers retrieve exactly the data they need rather than fetching everything and processing it client-side. Filtering narrows results by field values (?status=active), sorting orders them (?sort=created\_at&order=desc), and search allows freetext or fuzzy matching across fields. Designing these using predictable query parameter names and clearly documenting supported combinations is a significant part of API usability.
 
 Visit the following resources to learn more:
 

src/data/roadmaps/api-design/content/naming-conventions@0yY_lWzWVOC_WmPoyHw8W.md

@@ -1,6 +1,6 @@
 # Naming Conventions
 
-Naming conventions are the rules you follow to keep your API's URLs, parameters, and field names consistent and predictable. This includes decisions like using plural nouns for collections (/users not /user), lowercase kebab-case for URLs, camelCase or snake_case for JSON fields, and avoiding verbs in resource paths. Consistent naming reduces friction for developers consuming your API and signals that the API was designed deliberately rather than assembled ad hoc.
+Naming conventions are the rules you follow to keep your API's URLs, parameters, and field names consistent and predictable. This includes decisions like using plural nouns for collections (/users not /user), lowercase kebab-case for URLs, camelCase or snake\_case for JSON fields, and avoiding verbs in resource paths. Consistent naming reduces friction for developers consuming your API and signals that the API was designed deliberately rather than assembled ad hoc.
 
 Visit the following resources to learn more:
 

src/data/roadmaps/api-design/content/oidc@jWekRGRa1131w92oS1HeW.md

@@ -1,5 +1,6 @@
-OIDC
-OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. While OAuth 2.0 handles authorization (what you can do), OIDC handles authentication (who you are). It introduces the concept of an ID token, a signed JWT that contains claims about the authenticated user, such as their name, email, and user ID. OIDC is the standard behind "Sign in with Google / GitHub / Apple" flows and is the correct choice when your API needs to verify a user's identity, not just their permissions.
+# undefined
+
+OIDC OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. While OAuth 2.0 handles authorization (what you can do), OIDC handles authentication (who you are). It introduces the concept of an ID token, a signed JWT that contains claims about the authenticated user, such as their name, email, and user ID. OIDC is the standard behind "Sign in with Google / GitHub / Apple" flows and is the correct choice when your API needs to verify a user's identity, not just their permissions.
 
 Visit the following resources to learn more: