Multi-workflow mode should replace single-config mode, not run alongside it

[intel352]

Context

Issue #71 asked to resolve a dead TODO in cmd/server/main.go about multi-workflow mode wiring. PR #105 implemented it by running multi-workflow mode as a second HTTP server on a separate port alongside the existing single-config engine. This was closed because the architecture is wrong.

Problem

The current design (from PR #105, now reverted) runs both modes simultaneously:

cmd/server -config admin.yaml -database-dsn postgres://...
              │                         │
              ▼                         ▼
    Single-config engine       Multi-workflow API (:8090)
    on main port (:8081)       separate server, separate port

This creates:

• Two HTTP servers on two ports — confusing for users and operators
• Redundant engines — single-config is just N=1 workflows
• Meaningless -config flag — if workflows are API-managed via PostgreSQL, why also require a YAML file?
• Split lifecycle — shutdown must coordinate two servers and two engine sets

Correct Architecture

Multi-workflow mode is a superset of single-config mode. When -database-dsn is provided:

1. One server, one port. The existing HTTP server serves both the admin UI and the multi-workflow REST API on the same address.
2. One engine manager. WorkflowEngineManager manages all workflow engines, including any seeded from a config file.
3. -config becomes a seed flag. If provided alongside -database-dsn, the YAML config is imported as the initial workflow into the database on first run. It is not run as a separate engine.
4. Without -database-dsn, existing single-config behavior is preserved unchanged (full backward compatibility).

# Single-config mode (unchanged, backward compatible)
cmd/server -config admin.yaml

# Multi-workflow mode (replaces single-config, one server)
cmd/server -database-dsn postgres://... -jwt-secret ...

# Multi-workflow mode with initial seed
cmd/server -database-dsn postgres://... -jwt-secret ... -config admin.yaml

Implementation Notes

• The api package router should be mounted on the existing HTTP mux, not on a separate http.Server
• WorkflowEngineManager already exists and handles start/stop lifecycle
• The -config seed import can reuse loadConfig() → store workflow in PostgreSQL → let engine manager deploy it
• Auth middleware from the api package wraps only the /api/v1/ routes, not the admin UI routes

Replaces

• PR fix(server): implement multi-workflow mode API wiring #105 (closed)
• Issue Audit and resolve dead API wiring TODO in cmd/server/main.go #71 (the original TODO audit)