Introduce v0.1 version of the API (#658)

<!-- Provide a brief summary of your changes -->

## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
The following PR adds a new v0.1 API version. 

The goal is to mark v0.1 as a "freeze" point while keeping v0 as the
moving target for new features so integrators can start building on top
of something stable(r).

Details:
* This change is quite simple - we re-register the same handlers twice,
once as `v0` and once as `v0.1`
* Going forward, we'll keep v0.1 frozen while we add changes either on
top of both (non-breaking) or we'll have to branch if breaking changes
are necessary
* We all acknowledge this is not exactly best-practice, but it gives us
a way to gather feedback and allow clients to start integrating with the
API without breaking them (**note** this implies a follow up PR that
would branch the handlers used in v0.1).
* For integrators/clients: please provide your feedback - what works
well, what doesn't so we can take this into account going towards GA.

## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->

## Breaking Changes
<!-- Will users need to update their code or configurations? -->
No, this just adds a new API version alongside the existing one.

## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update

## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [ ] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [ ] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed

## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
Fixes: #649

Signed-off-by: Radoslav Dimitrov <radoslav@stacklok.com>

docs/guides/consuming/use-rest-api.md

@@ -4,13 +4,20 @@ Integration patterns and best practices for building applications that consume M
 
 ## Key details
 
-**Base URL**: `https://registry.modelcontextprotocol.io`  
+**Base URL**: `https://registry.modelcontextprotocol.io`
 
 **Authentication**: Not required for read-only access
 
-- **`GET /v0/servers`** - List all servers with pagination
-- **`GET /v0/servers/{serverName}/versions`** - List all versions of a server
-- **`GET /v0/servers/{serverName}/versions/{version}`** - Get specific version of server. Use the special version `latest` to get the latest version.
+**API Versions**:
+- `/v0/` - Development version with latest features (may receive additive changes)
+- `/v0.1/` - Stable version (only backward-compatible changes)
+
+**Recommendation**: Use `/v0.1/` for production applications requiring API stability. Both versions currently have identical functionality.
+
+**Core endpoints:**
+- **`GET /v0.1/servers`** - List all servers with pagination
+- **`GET /v0.1/servers/{serverName}/versions`** - List all versions of a server
+- **`GET /v0.1/servers/{serverName}/versions/{version}`** - Get specific version of server. Use the special version `latest` to get the latest version.
 
 Server names and version strings should be URL-encoded in paths.
 

docs/reference/api/CHANGELOG.md

@@ -4,6 +4,24 @@ Changes to the REST API endpoints and responses.
 
 ## Unreleased
 
+### Added
+
+#### API Versioning - v0.1 Introduction
+
+Introduced `/v0.1/` as a stable API version while `/v0/` continues as the development version.
+
+**New version paths:**
+- All `/v0/` endpoints are now also available at `/v0.1/`
+- Both versions currently share identical behavior
+- `/v0/` will continue to evolve with additive changes (new optional fields, new endpoints)
+- `/v0.1/` will remain stable with only additive, backward-compatible changes
+- Both versions will be maintained until a future v1.0 release
+
+**Migration guidance:**
+- Production applications should consider using `/v0.1/` for stability
+- Development and testing can continue using `/v0/` for latest features
+- No immediate action required - `/v0/` remains fully supported
+
 ### ⚠️ BREAKING CHANGES
 
 #### Endpoint Simplification