Clarify that create_or_update_file content is plain text

The content parameter is passed to the API as plain text and the server
base64-encodes it, but the description said only "Content of the file".
The REST endpoint this wraps documents its own content field as base64,
so a model reading the tool description has a strong reason to encode the
content itself. When it does, the server encodes again and the file is
committed containing base64 text. Every layer reports success.

Describe the value by how it should end up on disk rather than by what
not to do, so a file whose contents are legitimately base64 is still
unambiguous, and name the encoding step so the conflict with the REST
API docs is resolved rather than merely overridden.

Author: ericsciple

README.md

@@ -1278,7 +1278,7 @@ The following sets of tools are available:
 - **create_or_update_file** - Create or update file
   - **Required OAuth Scopes**: `repo`
   - `branch`: Branch to create/update the file in (string, required)
-  - `content`: Content of the file (string, required)
+  - `content`: Content of the file, exactly as it should appear once written. Do not base64-encode it; this server does that before calling the REST API. (string, required)
   - `message`: Commit message (string, required)
   - `owner`: Repository owner (username or organization) (string, required)
   - `path`: Path where to create/update the file (string, required)

pkg/github/__toolsnaps__/create_or_update_file.snap

@@ -12,7 +12,7 @@
         "type": "string"
       },
       "content": {
-        "description": "Content of the file",
+        "description": "Content of the file, exactly as it should appear once written. Do not base64-encode it; this server does that before calling the REST API.",
         "type": "string"
       },
       "message": {

pkg/github/repositories.go

@@ -436,7 +436,7 @@ SHA MUST be provided for existing file updates.
 					},
 					"content": {
 						Type:        "string",
-						Description: "Content of the file",
+						Description: "Content of the file, exactly as it should appear once written. Do not base64-encode it; this server does that before calling the REST API.",
 					},
 					"message": {
 						Type:        "string",