Add configurable service manifest endpoint at GET / and GET /v1

[Copilot]

Implements a service manifest endpoint exposing API metadata and available endpoints for programmatic discovery.

Changes

Endpoints: GET / and GET /v1 (public, no auth required)

Returns JSON manifest with:

• Service metadata: name, versions, description, documentation URL, serviceVersion (now configurable)
• Authentication schemes (OpenAPI-compatible)
• All 27 API endpoints as RFC6570 URI templates with methods, descriptions, and tags

Routing: Registered at both / (using /{$} for exact match) and /v1 for API discovery at both version-agnostic and versioned roots.

Configurable fields: Users can customize manifest metadata via environment variables:

• SERVICE_API_NAME - Service name (default: "DHaMPS Vector Database API")
• SERVICE_API_DESCRIPTION - Service description (default: built-in description)
• SERVICE_API_DOC_URL - Documentation URL (default: "https://mpilhlt.github.io/embapi/")

Set these in your .env file to override defaults.

Code organization:

• internal/models/manifest.go - manifest data structures
• internal/handlers/manifest.go - handler implementation with manually-maintained endpoint list, uses configurable values
• internal/models/options.go - extracted constants and added configurable fields
• Updated main.go and test files to pass Options through handler chain
• Documented configuration in template.env and README

Example response:

{
  "name": "DHaMPS Vector Database API",
  "versions": ["v1"],
  "serviceVersion": "0.0.1",
  "documentation": "https://mpilhlt.github.io/embapi/",
  "authentication": {
    "adminAuth": {"type": "http", "scheme": "bearer", ...},
    ...
  },
  "endpoints": [
    {
      "path": "/v1/users/{user_handle}",
      "methods": ["GET", "PUT", "DELETE"],
      "description": "Manage a specific user",
      "tags": ["users"]
    },
    ...
  ]
}

Updated README Quick Start with manifest discovery step and configuration instructions.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[awagner-mainz]

@copilot I would prefer that users of this server software are able to define some of the manifest fields - like name, description, link to documentation - themselves in the configuration. Please provide them with a means to do so (e.g. make these values configurable in a config file, or choose another option, like env fields if you think that would be better). Keep the present values as default values in case the user does not specify otherwise.

Also, you said it would be better to offer the manifest at both the versioned and version-less endpoint. I found that plausible: While at the moment that would mean the same manifest would be reported at two different endpoints, in later versions of the API this could become useful. Please add it to the very root (/) in addition to the versioned root that you now have (/v1).

[Copilot]

@copilot I would prefer that users of this server software are able to define some of the manifest fields - like name, description, link to documentation - themselves in the configuration. Please prov...

Done! The manifest fields are now configurable via environment variables, and the endpoint is available at both / and /v1.

Configuration: Set in .env file or environment:

• SERVICE_API_NAME - Service name
• SERVICE_API_DESCRIPTION - Service description
• SERVICE_API_DOC_URL - Documentation URL

All fields default to current values if not specified. The implementation uses /{$} for exact root path matching (Go 1.22+ syntax) to prevent the root handler from catching unmatched paths. See commit cb15603.

[awagner-mainz]

Looks good.