fix(plugin): keep the new JAR when a replace commit outcome is unknown #118

Problem Description

In DynamicJobLoaderService.doReplaceJar, any RuntimeException from the replace transaction (lifecycleTransaction.execute(...)) leads to discardStoredJar, which deletes the new JAR. Some commit failures have an unknown outcome: the database may have committed the new jar_file_path even though the call threw (for example, the connection dropped after the commit was sent). In that case the definition points at a JAR file that was just deleted, and the next load fails.

Proposed Solution

Before deleting the new JAR after a transaction failure, re-read the definition. Delete the new JAR only when the definition does not reference it. If the definition does reference it, keep the file, delete the previous JAR as on success, and audit the outcome. If the definition cannot be read, keep the new JAR and report it as a possible orphan instead of deleting it.

Acceptance Criteria

• A transaction failure where the definition already references the new JAR keeps the new JAR on disk.
• A transaction failure where the definition still references the previous JAR deletes the new JAR, as today.
• If the definition cannot be re-read, the new JAR is kept and the audit names it as a possible orphan.
• Tests cover all three outcomes.

Affected Area

Plugin lifecycle: job definition JAR replace

Out of Scope

• Distributed transactions between the database and the file system.

Additional Context

Follow-up to #108 / PR #113.