feat: service accounts with scoped virtual key self-provisioning

[farovictor]

Summary

• New ServiceAccount entity — separate from User, no management access
• POST /v1/service-token (auth via X-Service-Key) issues a short-lived virtual key without needing a user session
• Management CRUD behind normal user auth: POST/GET /v1/serviceaccounts, DELETE /v1/serviceaccounts/{id}
• allowed_services field: empty = allow any registered service, non-empty = restrict to listed service IDs
• Keys issued this way carry source: "sa" for traceability in usage logs
• Migration 011_create_service_accounts.sql

Design note

This is a flat v1 implementation — service accounts are global to the Bifrost instance. Org-scoped service accounts are documented as a future concern in pkg/serviceaccounts/serviceaccount.go.

Usage (CI/CD pipeline example)

# Admin creates a service account once
curl -X POST /v1/serviceaccounts \
  -H "X-API-Key: ..." -H "Authorization: Bearer ..." \
  -d '{"name":"my-pipeline","allowed_services":["openai"]}'
# → {"id":"...","api_key":"sa-xxx","allowed_services":["openai"]}

# Pipeline requests a key at runtime (no user session needed)
curl -X POST /v1/service-token \
  -H "X-Service-Key: sa-xxx" \
  -d '{"service":"openai","ttl_seconds":300}'
# → {"key":"vk-sa-...","expires_at":"..."}

Test plan

• TestCreateServiceAccount_OK — generates ID + api_key automatically
• TestCreateServiceAccount_MissingName — 400
• TestCreateServiceAccount_Duplicate — 409
• TestListServiceAccounts — returns all accounts
• TestDeleteServiceAccount_OK — 204
• TestDeleteServiceAccount_NotFound — 404
• TestServiceToken_OK — returns key with correct source
• TestServiceToken_MissingServiceKey — 401
• TestServiceToken_InvalidServiceKey — 401
• TestServiceToken_ServiceNotAllowed — 403
• TestServiceToken_ServiceNotFound — 404
• TestServiceToken_EmptyAllowedServicesAllowsAny — 200

🤖 Generated with Claude Code