fix(server): harden multi-workflow mode startup and wiring

[Copilot]

Multi-workflow mode had several gaps: the engine manager was never wired into the API (deploy/stop only updated DB status), admin bootstrap masked real DB errors, shutdown had no timeout, port conflicts failed silently, and single-config mode ran concurrently instead of being excluded.

API layer — engine manager wiring

Added EngineRunner interface to the api package and wired it through Config.Engine → WorkflowHandler:

// EngineRunner is satisfied by *workflow.WorkflowEngineManager
type EngineRunner interface {
    DeployWorkflow(ctx context.Context, workflowID uuid.UUID) error
    StopWorkflow(ctx context.Context, workflowID uuid.UUID) error
}

Deploy and Stop handlers now call the engine before persisting the status change. Without an engine set (e.g. tests, legacy path) behaviour is unchanged.

cmd/server/main.go — startup hardening

• JWT guard: log.Fatal when --jwt-secret is empty — tokens would be forgeable otherwise
• DB timeout: NewPGStore + migrator.Migrate use a 30-second context.WithTimeout instead of context.Background()
• Admin bootstrap: errors.Is(err, evstore.ErrNotFound) now gates creation; any other error is fatal rather than silently retried
• Fail-fast listener: net.Listen called before the deferred cleanup block — port conflicts are fatal immediately
• Bounded shutdown: apiServer.Shutdown + engineMgr.StopAll share a 30-second timeout context; deadline exceeded is logged as a warning
• Mode exclusion: multi-workflow block blocks on SIGINT/SIGTERM then returns, preventing single-config mode from running alongside it

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.