Issue #1264 keeps surfacing because RFC 9728 §3.3 requires strict equality between the client's resource identifier and the resource value advertised in protected resource metadata, but the public surface of AuthSettings.resource_server_url does not say this. PR #1407 established the contract that resource_server_url must be the full endpoint URL including the transport path, and the simple-auth example was updated, but the matching examples/snippets/servers/oauth_server.py snippet (which is rendered into README.v2.md by scripts/update_readme_snippets.py) still passes http://localhost:3001 with no path, the AuthSettings.resource_server_url description still says only "URL of the MCP server", and simple-auth/server.py hardcodes /mcp even when the user passes --transport=sse.

This change updates the AuthSettings.resource_server_url field description to spell out the contract, including the requirement that the URL include the transport path and the reference to RFC 9728 §3.3. The oauth_server.py snippet is changed to http://localhost:3001/mcp with a comment explaining why, and README.v2.md is regenerated so the embedded snippet matches. In simple-auth/server.py, the override that built server_url picks /sse or /mcp based on the --transport flag so the SSE path no longer produces an RFC 9728 mismatch.

Per the closing comment on #2189, the maintainer asked for a docs and example fix here rather than auto-appending streamable_http_path, because streamable_http_path is an internal Starlette route and not always the public URL (for example when the app is mounted at /api with streamable_http_path="/", or behind a reverse proxy). Verified with uv run --frozen ruff check, uv run --frozen pyright, uv run --frozen pytest tests/server/auth/ tests/server/mcpserver/ (388 passed), and uv run --frozen python scripts/update_readme_snippets.py --check.

Refs #1264