fix: treat resource metadata JSON parse failure as soft error

[jh-block]

Summary

fetch_resource_metadata_from_url returns a fatal AuthError::MetadataError when the resource metadata response body cannot be parsed as JSON. This prevents discover_metadata() from falling through to direct .well-known/oauth-authorization-server discovery (Strategy B).

Problem

MCP servers that return HTTP 200 with non-JSON content (e.g. HTML) at their base URL cause the resource metadata probe to "succeed" at the HTTP level (200 = "this is the metadata URL"), but then the JSON deserialization fails fatally. The OAuth flow aborts entirely even though the server has a valid .well-known/oauth-authorization-server endpoint.

Users see "Auth required" with no OAuth browser flow ever opening.

Fix

Treat JSON parse errors as a soft failure — return Ok(None) with a debug! log — consistent with how HTTP errors (non-200 status codes) are already handled in the same function. This allows discover_metadata() to continue and attempt direct authorization server metadata discovery.

Test plan

• Verified the project compiles with cargo check -p rmcp --features auth
• Existing tests continue to pass
• Servers returning valid resource metadata JSON are unaffected (happy path unchanged)
• Servers returning non-JSON at their base URL now correctly fall through to .well-known/oauth-authorization-server discovery instead of aborting

[jh-block]

Note that an alternative here would be to not try to parse this response as metadata at all, since fetching the MCP server URL itself and treating it as the metadata isn't part of the discovery flow in the spec. But I am assuming this variation from the spec is intentional for some reason (compatibility with non-compliant servers maybe?) so kept this change minimal.