feat(plugin): support replacing definitions that have execution history #108

Problem Description

Since #94 / PR #105, a job definition with execution history cannot be deleted: DELETE returns 409 and the documented alternative is to disable it. JarUploadService rejects an upload whose job name already exists (DuplicateJobDefinitionException). Together, these block the production-checklist rollback step of uploading a previous working version under the same job name: the disabled definition keeps the name forever. job_executions_audit.job_definition_id is NOT NULL with a foreign key to job_definitions and no cascade (V1__job_registry_tables.sql).

Proposed Solution

Define a supported way to replace or roll back a plugin whose definition has execution history while keeping the audit trail. Options to evaluate:

• Versioned definitions: allow a new definition for the same job name when the previous one is disabled, keeping history linked to the old definition.
• In-place JAR replacement for an existing definition, with reload, keeping the same definition id.
• Archiving: detach history from the definition (nullable FK or archive table) so the old definition can be removed.

Document the chosen procedure in the production checklist and runbook.

Acceptance Criteria

• An operator can roll back or replace a plugin that has execution history without losing its execution audit trail.
• The chosen procedure is documented in the production checklist and runbook, and the current "upload the previous working version" step is updated.
• Any schema change ships as a new Flyway migration.
• Tests cover the replacement path, including history preservation.

Affected Area

Plugin lifecycle: definition upload, replacement, and rollback

Out of Scope

• Distributed locking.
• Changing DELETE semantics for definitions without history.

Additional Context

Follow-up to #94 / PR #105. The rollback gap is noted in fr-batch-service/docs/production-checklist.md.