fix: respect resource mime type in responses

The server was ignoring mime types set on resources, defaulting to text/plain
for strings and application/octet-stream for bytes. Now properly preserves
the specified mime type in both FastMCP and low-level server implementations.

Note that this is breaks backwards compatibility as it changes the return
values of read_resource() on FastMCP. It is BC compatible on lowlevel since
it only extends the callback.

Github-Issue: #152
Reported-by: eiseleMichael

CLAUDE.md

@@ -25,16 +25,31 @@ This document contains critical information about working with this codebase. Fo
    - New features require tests
    - Bug fixes require regression tests
 
-4. Version Control
-   - Commit messages: conventional format (fix:, feat:)
-   - PR scope: minimal, focused changes
-   - PR requirements: description, test plan
-   - Always include issue numbers
-   - Quote handling:
-     ```bash
-     git commit -am "\"fix: message\""
-     gh pr create --title "\"title\"" --body "\"body\""
-     ```
+- For commits fixing bugs or adding features based on user reports add:
+  ```bash
+  git commit --trailer "Reported-by:<name>"
+  ```
+  Where `<name>` is the name of the user.
+
+- For commits related to a Github issue, add
+  ```bash
+  git commit --trailer "Github-Issue:<number>"
+  ```
+- NEVER ever mention a `co-authored-by` or similar aspects. In particular, never
+  mention the tool used to create the commit message or PR.
+
+## Pull Requests
+
+- Create a detailed message of what changed. Focus on the high level description of
+  the problem it tries to solve, and how it is solved. Don't go into the specifics of the
+  code unless it adds clarity.
+
+- Always add `jerome3o-anthropic` and `jspahrsummers` as reviewer.
+
+- NEVER ever mention a `co-authored-by` or similar aspects. In particular, never
+  mention the tool used to create the commit message or PR.
+
+## Python Tools
 
 ## Code Formatting
 
@@ -96,4 +111,4 @@ This document contains critical information about working with this codebase. Fo
    - Keep changes minimal
    - Follow existing patterns
    - Document public APIs
-   - Test thoroughly
+   - Test thoroughly