Implement Integration Config Service uniqueness enforcement

Add uniqueness enforcement as a decorator or mixin layer on top of the IntegrationConfigService from task-010 — do not intermingle the uniqueness logic with the base CRUD methods. This keeps each concern separately testable. Implement an existsActiveConfig(orgId, integrationType): Promise private method that checks the database before any create attempt. For replaceIntegrationConfig, use a Postgres transaction with two operations: UPDATE existing set status='replaced', then INSERT new record.

Wrap in a database function/stored procedure for true atomicity. The user-friendly conflict message should include enough context for the UI wizard to render an actionable prompt — include existingConfigId so the wizard can call replaceIntegrationConfig directly. For the race condition safety net: catch Postgres unique_violation error code (23505) in the createIntegrationConfig catch block and convert it to ConfigConflictError with a generic message ('Configuration was created by another session — please refresh and try again'). The database-level unique index should be: CREATE UNIQUE INDEX ON integration_configs(org_id, integration_type) WHERE status = 'active' — this is a partial unique index that only enforces uniqueness on active records, which matches the business rule exactly.

Unit tests (Deno test): conflict detected when active config exists (mock repository returns existing record), conflict NOT detected when only soft-deleted configs exist (status != 'active'), ConfigConflictError contains all required fields for UI rendering, replaceIntegrationConfig deactivates old and creates new atomically (verify both operations called in correct order), rollback when new config creation fails mid-replace (verify old config re-activated), upgradeIntegrationConfig updates fields without creating new record, database constraint violation mapped to ConfigConflictError (not raw Postgres error), concurrent conflict race condition test using two simultaneous create calls. Test coverage target: 95%. All tests use mock repository and transaction mock — no live database required.