Update several spots where C-S API was still using r0 APIs

changelogs/client_server/newsfragments/3671.clarification

@@ -0,0 +1 @@
+Fix various typos throughout the specification.

content/client-server-api/_index.md

@@ -454,7 +454,7 @@ given. It also contains other keys dependent on the auth type being
 attempted. For example, if the client is attempting to complete auth
 type `example.type.foo`, it might submit something like this:
 
-    POST /_matrix/client/r0/endpoint HTTP/1.1
+    POST /_matrix/client/v3/endpoint HTTP/1.1
     Content-Type: application/json
 
 ```json

content/client-server-api/modules/end_to_end_encryption.md

@@ -886,11 +886,11 @@ key, then Alice's device can trust Bob's master key, and she can sign it
 with her user-signing key.
 
 Users upload their cross-signing keys to the server using [POST
-/\_matrix/client/r0/keys/device\_signing/upload](/client-server-api/#post_matrixclientv3keysdevice_signingupload). When Alice uploads
+/\_matrix/client/v3/keys/device\_signing/upload](/client-server-api/#post_matrixclientv3keysdevice_signingupload). When Alice uploads
 new cross-signing keys, her user ID will appear in the `changed`
 property of the `device_lists` field of the `/sync` of response of all
 users who share an encrypted room with her. When Bob sees Alice's user
-ID in his `/sync`, he will call [POST /\_matrix/client/r0/keys/query](/client-server-api/#post_matrixclientv3keysquery)
+ID in his `/sync`, he will call [POST /\_matrix/client/v3/keys/query](/client-server-api/#post_matrixclientv3keysquery)
 to retrieve Alice's device and cross-signing keys.
 
 If Alice has a device and wishes to send an encrypted message to Bob,
@@ -1194,17 +1194,17 @@ However, as the session keys are stored on the server encrypted, it
 requires users to enter a decryption key to decrypt the session keys.
 
 To create a backup, a client will call [POST
-/\_matrix/client/r0/room\_keys/version](#post_matrixclientv3room_keysversion) and define how the keys are to
+/\_matrix/client/v3/room\_keys/version](#post_matrixclientv3room_keysversion) and define how the keys are to
 be encrypted through the backup's `auth_data`; other clients can
 discover the backup by calling [GET
-/\_matrix/client/r0/room\_keys/version](#get_matrixclientv3room_keysversion). Keys are encrypted according
+/\_matrix/client/v3/room\_keys/version](#get_matrixclientv3room_keysversion). Keys are encrypted according
 to the backup's `auth_data` and added to the backup by calling [PUT
-/\_matrix/client/r0/room\_keys/keys](#put_matrixclientv3room_keyskeys) or one of its variants, and can
-be retrieved by calling [GET /\_matrix/client/r0/room\_keys/keys](#get_matrixclientv3room_keyskeys) or
+/\_matrix/client/v3/room\_keys/keys](#put_matrixclientv3room_keyskeys) or one of its variants, and can
+be retrieved by calling [GET /\_matrix/client/v3/room\_keys/keys](#get_matrixclientv3room_keyskeys) or
 one of its variants. Keys can only be written to the most recently
 created version of the backup. Backups can also be deleted using [DELETE
-/\_matrix/client/r0/room\_keys/version/{version}](#delete_matrixclientv3room_keysversionversion), or individual keys
-can be deleted using [DELETE /\_matrix/client/r0/room\_keys/keys](#delete_matrixclientv3room_keyskeys) or
+/\_matrix/client/v3/room\_keys/version/{version}](#delete_matrixclientv3room_keysversionversion), or individual keys
+can be deleted using [DELETE /\_matrix/client/v3/room\_keys/keys](#delete_matrixclientv3room_keyskeys) or
 one of its variants.
 
 Clients must only store keys in backups after they have ensured that the

data/api/client-server/key_backup.yaml

@@ -172,7 +172,7 @@ paths:
           description: |-
             The backup version to get, as returned in the `version` parameter
             of the response in
-            [`POST /_matrix/client/r0/room_keys/version`](/client-server/#post_matrixclientv3room_keysversion)
+            [`POST /_matrix/client/v3/room_keys/version`](/client-server-api/#post_matrixclientv3room_keysversion)
             or this endpoint.
           required: true
           x-example: "1"
@@ -254,8 +254,8 @@ paths:
           description: |-
             The backup version to update, as returned in the `version`
             parameter in the response of
-            [`POST /_matrix/client/r0/room_keys/version`](/client-server-api/#post_matrixclientv3room_keysversion)
-            or [`GET /_matrix/client/r0/room_keys/version/{version}`](/client-server-api/#get_matrixclientv3room_keysversionversion).
+            [`POST /_matrix/client/v3/room_keys/version`](/client-server-api/#post_matrixclientv3room_keysversion)
+            or [`GET /_matrix/client/v3/room_keys/version/{version}`](/client-server-api/#get_matrixclientv3room_keysversionversion).
           required: true
           x-example: "1"
         - in: body
@@ -343,8 +343,8 @@ paths:
           description: |-
             The backup version to delete, as returned in the `version`
             parameter in the response of
-            [`POST /_matrix/client/r0/room_keys/version`](/client-server-api/#post_matrixclientv3room_keysversion)
-            or [`GET /_matrix/client/r0/room_keys/version/{version}`](/client-server-api/#get_matrixclientv3room_keysversionversion).
+            [`POST /_matrix/client/v3/room_keys/version`](/client-server-api/#post_matrixclientv3room_keysversion)
+            or [`GET /_matrix/client/v3/room_keys/version/{version}`](/client-server-api/#get_matrixclientv3room_keysversionversion).
           required: true
           x-example: "1"
       responses:

data/event-schemas/schema/core-event-schema/unsigned_prop.yaml

@@ -29,7 +29,7 @@ properties:
   transaction_id:
     description: |
       The client-supplied transaction ID, for example, provided via
-      `PUT /_matrix/client/r0/rooms/{roomId}/send/{eventType}/{txnId}`,
+      `PUT /_matrix/client/v3/rooms/{roomId}/send/{eventType}/{txnId}`,
       if the client being given the event is the same one which sent it.
     type: string
   prev_content: