fix(plugin): return 409 when delete races an execution across instances #110

Problem Description

DynamicJobLoaderService.deleteJob (#94, PR #105) checks execution history before the delete transaction. The per-definition lifecycle lock is JVM-local, so with more than one service instance an execution can start between the history check and the commit. The delete then fails on the job_executions_audit foreign key and returns a generic 500 instead of the documented 409, after the plugin has already been unloaded on that instance.

Proposed Solution

Make the history guard and the delete consistent across instances without introducing distributed locking. Options to evaluate:

• Translate the foreign-key violation on delete into JobDeleteConflictException (409) with a FAILURE audit.
• Re-check history inside the delete transaction, with a row lock on the definition (for example SELECT ... FOR UPDATE) that execution start also respects.

Document the multi-instance behavior in the production checklist.

Acceptance Criteria

• A delete that races with an execution start returns 409, never a generic 500.
• The FAILURE audit for that case names the reason.
• The multi-instance behavior and any remaining limits are documented.
• A test covers the race outcome (for example by simulating the foreign-key violation).

Affected Area

Plugin lifecycle: job definition deletion

Out of Scope

• Distributed locking across instances.

Additional Context

Follow-up to #94 / PR #105. The production checklist already documents that lifecycle locks are JVM-local.