fix(plugin): handle initial LOADING persistence failures

[fronzec]

Problem Description

DynamicJobLoaderService.doLoadJob sets a definition to LOADING and persists that state before entering the main load error-handling block. If this initial persistence fails, the failure is not normalized through the loader failure path. The definition can be left with an inconsistent LOADING state, the original error can escape without the expected failure metadata, and recovery behavior is undefined.

Proposed Solution

Harden the initial lifecycle-state persistence so every load attempt has an explicit failure outcome:

• Include the initial LOADING transition in the load failure boundary.
• Preserve the original persistence failure and avoid masking it with cleanup or best-effort failure persistence errors.
• Attempt to persist FAILED with a useful error when the repository becomes available, while keeping observability when failure persistence is also unavailable.
• Ensure no classloader or registry ownership is created or retained when the initial state transition fails.

Acceptance Criteria

• A failure while persisting the initial LOADING state does not escape as an unexplained or successful load.
• The definition cannot remain falsely represented as an active load after the failure path completes.
• The original exception is retained in logs and in the resulting loadError whenever persistence permits.
• Failure persistence errors are recorded without replacing the original cause.
• No stale classloader or plugin registry entry remains after this failure path.
• Focused tests cover initial-save failure, failure-save failure, lock release, and subsequent retry/recovery behavior.

Affected Area

DynamicJobLoaderService.doLoadJob and its lifecycle-state persistence behavior.

Out of Scope

• DELETE safety and unload semantics.
• Distributed locking.
• Reworking the lifecycle serialization already delivered by feat(plugin): serialize lifecycle transitions and preserve reload failure state #86.

Additional Context

Follow-up to #86. The initial LOADING persistence follow-up was explicitly excluded from that issue.