feat(api): Add pipeline trigger endpoint with multi-provider support

[SergK]

Is your feature request related to a problem? Please describe.
Teams need a unified way to trigger CI/CD pipelines across multiple Git providers (GitLab today, GitHub/Bitbucket next) without bespoke provider-specific clients or manual API calls. This causes fragmentation, duplicate logic, and inconsistent error handling.

Describe the solution you'd like
Add a new REST API endpoint to GitFusion to trigger pipelines across providers via a single interface:

• Endpoint: POST /api/v1/trigger-pipeline
• Query params: gitServer, project, ref, variables (JSON array of {key, value, variableType})
• Behavior:
  • Resolve provider settings from Kubernetes (GitServer CR + Secret)
  • Route to the correct provider via multi-provider service
  • Trigger pipeline and return id, web_url, status, ref, sha
• Error handling:
  • 400: invalid/missing params, invalid variables JSON
  • 401: unauthorized provider credentials
  • 404: project/ref not found
  • 500: unexpected provider errors
• OpenAPI:
  • Update internal/api/oapi.yaml with request/response models and error schemas
• Quality:
  • Input validation added at handler
  • Consistent error mapping and messages
  • Unit tests for pure logic and dispatch error paths

Describe alternatives you've considered

• Separate provider-specific endpoints per Git provider (more surface area, duplication)
• Client-side direct calls to GitLab/GitHub/Bitbucket APIs (inconsistent security, error handling)
• Webhooks-based triggering (doesn’t cover on-demand pipeline starts with parameters)

Git provider specific details

• Implemented: GitLab provider (pipeline creation with variable support)
• Planned: GitHub and Bitbucket providers via the same PipelineProvider interface, registered in MultiProviderPipelineService
• Variables supported: env-var and file types (mapped to provider-specific variable types)

Additional context

• Commit scope: feat(api) add pipeline trigger endpoint with multi-provider support
• OpenAPI updated; new handler, service, and provider added
• Tests:
  • 100% coverage for variable conversion helper
  • 75% coverage for unsupported-provider dispatch path
  • Integration tests are scaffolded and skipped (require real GitLab/K8s)
  • Overall pipelines package coverage: 40% (better than existing 0% for similar services)
• Principles: DRY, KISS, YAGNI, SOLID followed (no over-engineering, extensible provider model)

Acceptance Criteria

• POST /api/v1/trigger-pipeline returns 201 with id, web_url, status, ref, sha (when available)
• Returns 400 for missing/invalid params and invalid variables JSON
• Returns 401 for invalid provider credentials
• Returns 404 for unknown project/ref
• OpenAPI spec reflects request/response and error models
• Unit tests cover pure logic and dispatch error paths
• Integration test placeholders exist for GitLab and k8s

Next steps

• Implement GitHub/Bitbucket providers
• Add CI integration tests against a GitLab test instance and a k8s env (kind) for GitServer CR/Secret resolution