[BUG] SOC→NC warm-start condition is inverted, and NC results are adopted without checking the termination status

[joda9]

Intended behaviour (two-stage solve)

Stage 1: SOC relaxation (Gurobi). If the SOC solution is tight, it is already AC-feasible —
done, no NC solve needed. If it is not tight, the relaxed solution is physically infeasible
and stage 2 should rescue feasibility: solve the exact non-convex model (Ipopt) warm-started
from the SOC solution. (This is also what the SOCBFPowerModelEdisgo docstring describes.)

Actual behaviour (eDisGo_OPF.jl/Main.jl)

1. Condition inverted: if soc_tight & warm_start — the NC polish runs only in the tight
   case (where it is unnecessary), and is skipped exactly when the SOC solution is not tight.
   A non-tight relaxed solution is returned to eDisGo as the result (only a violations JSON is
   written to opf_solutions/).
2. No termination-status check on the NC result: result_nc_ws is adopted unconditionally
   via update_data!. If Ipopt ends LOCALLY_INFEASIBLE/ITERATION_LIMIT, a worse-than-SOC
   solution is silently returned. The same unconditional adoption exists in the method="nc"
   cold-start path.
3. Rescue gated behind an opt-in flag: warm_start defaults to False in pm_optimize,
   so out of the box a non-tight solution is never rescued.

Fix

• Run the NC rescue when !soc_tight (regardless of the warm_start flag); skip the NC solve
  when the SOC solution is tight.
• Check the NC termination/primal status: on success adopt the NC solution, otherwise fall back
  to the SOC solution and log a loud warning. Apply the same status check to method="nc".