feat: service accounts & REST API

[TerrifiedBug]

Summary

• Add ServiceAccount model with hashed API key storage, environment scoping, granular permissions, and optional expiration
• Implement tRPC router for service account CRUD (list, create, revoke, delete) with ADMIN access and audit logging
• Add API key authentication middleware for Bearer token validation with SHA-256 hash lookup
• Create 12 REST API endpoints under /api/v1/ for pipelines, nodes, secrets, alerts, and audit log
• Build frontend settings page with create dialog, one-time key display, permission toggles, and revoke/delete flows
• Write full documentation: service accounts operations guide and REST API reference with curl examples

Test plan

• Create a service account via the Settings UI and verify the API key is displayed once
• Use the generated API key to call GET /api/v1/pipelines and verify authentication works
• Verify a revoked service account returns 401
• Verify expired service accounts are rejected
• Test permission enforcement (e.g., pipelines.read key cannot call deploy endpoint)
• Test all 12 REST API endpoints with valid service account keys
• Verify audit log entries are created for service account operations
• Run Prisma migration on a fresh database

[greptile-apps]

Greptile Summary

All previous security and correctness issues have been properly addressed:

• Authorization & Data Isolation: Service account scope enforcement works correctly; teamId is derived server-side from environment context
• Audit Logging: All REST mutation endpoints (secrets, pipelines, nodes, alerts) properly log to audit trail via writeAuditLog
• Input Validation: Secrets routes correctly validate that either id or name is provided, returning 400 instead of misleading 404
• Sensitive Field Redaction: VectorNode REST responses use explicit select blocks that omit nodeTokenHash and pendingAction
• Error Handling: Cursor-based pagination validates cursors before queries; generic error messages prevent Prisma schema leakage; TRPCErrors map to correct HTTP status codes (404, 400, etc.)
• API Authentication: Bearer token validation and permission checks are enforced on all routes via the apiRoute wrapper

One documented trade-off remains by design: service account IDs are passed to PipelineVersion.createdById (no FK constraint), causing version history author attribution to be non-user-resolvable for REST-triggered deployments. This is a semantic issue with no crash risk and was discussed in prior review rounds.

The implementation is production-ready for the REST API and service account features described in the PR.

Confidence Score: 5/5

• All critical findings from prior reviews have been addressed. The implementation correctly enforces environment-scoped access, logs all mutations, validates input, redacts sensitive fields, and maps errors to proper HTTP status codes.
• All seven security/correctness issues identified in previous review rounds are verified as fixed: server-side teamId derivation, comprehensive audit logging, explicit select blocks omitting sensitive fields, input validation returning proper error codes, cursor pre-validation, generic error messages, and TRPCError HTTP mapping. The one remaining trade-off (service account ID in PipelineVersion.createdById) is a documented semantic issue without crash risk and was intentionally retained.
• No files require special attention. All reviewed endpoints show correct implementation of security controls.

_{Last reviewed commit: bd94f87}