feat: First-Class Agent Versioning and Repository URL Support

We are evaluating integration of your gateway into our agentic platform and have been very impressed with the advertised capabilities. After deploying an instance in our development environment, we identified a few gaps that we would like to discuss.

## 1. Agent Versioning
When registering an agent through the UI form, it is possible to specify an `Agent Version` under `Additional Settings`. However, this value does not appear to be used to differentiate multiple versions of the same agent.

### Current Challenge
We would like to register multiple versions of the same agent simultaneously. For example:

- Existing production workloads have been validated against **Agent X v1**.
- A new version, **Agent X v2**, becomes available.
- Workload owners should be able to continue using v1 until they complete validation and choose to migrate to **v2**.

With the current implementation, this requires registering each version under a different path, for example:
```
/api/agents/agent_x/v1
/api/agents/agent_x/v2
```

While this approach works, it places the burden of version management on users and application developers. A similar issue for skills has been reported in #941 .

### Proposed Enhancement
We would like to see the `Agent Version` field become part of the agent's identity within the registry.
For example:

- An agent could have multiple registered versions.
- The registry could automatically handle version-aware routing or path generation.
- The data model could represent a single agent with multiple versions rather than treating each version as a completely separate registration.

This would provide first-class support for versioning and simplify lifecycle management for agents.
Is this a use case that aligns with the intended direction of the registry?

## 2. Repository Metadata
Related to agent registration, there is another field under `Additional Settings` called `Repository URL`.

Based on our review of the implementation, this field does not appear to be persisted or exposed through the API. It seems to exist only in the UI and is discarded when the user clicks `Register Agent`.

### Proposed Enhancement
We would like to see the `Repository URL` stored as part of the agent metadata and returned through the REST API.

### Use Case
We are building a CI/CD pipeline that automatically builds and publishes agent containers when:

- A new agent is registered, or
- A new version of an existing agent is registered.

In this workflow:

1. The registry would notify our automation pipeline of the registration event.
2. The pipeline would retrieve the agent's repository information from the registry.
3. The pipeline would build and deploy the corresponding agent artifact.

As an additional enhancement, it would be helpful if the repository reference could optionally include a subfolder path. This would allow multiple agents to be maintained within a single Git repository rather than enforcing a one-agent-per-repository model.

We recognize that this use case may be somewhat outside the registry's current scope. However, we would appreciate understanding the original intent of the `Repository URL` field and whether there are plans to support it in the future.

---
_Note: I can split those into two issues if required._