fix: graceful get_locals degradation on missing LocalVariableTable + honest wait_for_attach already-connected message

Two low-severity, pre-2.10.0 defects found while revalidating the 2.10.0 fixes.

* jdwp_get_locals: catch AbsentInformationException around the visibleVariables()
  loop, keep the 'this' line already appended, and degrade with an actionable hint
  instead of collapsing the whole response into the useless literal "Error: null".
  Mirrors the partial-output principle documented in appendMarkedInstancesFooter
  and the graceful degrade jdwp_get_breakpoint_context already does for the same
  exception.

* Null-message sweep: route every `"Error: " + e.getMessage()` catch through a new
  errorReply() helper that falls back to the exception's simple class name, so no
  tool can surface "Error: null" (34 sites in JDWPTools, plus the one sibling site
  in JDIConnectionService's object-field dump — 35 total across two files).

* jdwp_wait_for_attach: only append the "suspended at VM_START" guidance on a
  genuine fresh attach. connect()'s "Already connected" fast-path returns a
  pre-existing, mid-execution session, so it is now described as such and points at
  jdwp_diagnose / jdwp_disconnect for the same-port-restart recovery path instead
  of falsely asserting a VM_START suspension state.

Tests: new JDWPToolsGetLocalsAbsentInfoTest (3) and
JDWPToolsWaitForAttachAlreadyConnectedTest (2); updated the one existing test that
pinned the old "Error:" behavior for missing debug info. Full suite: 1075 pass.

Refs #36. The two deferred items in that issue (wait_for_attach PID-aware target
identity, off-classpath expression-eval diagnostics) remain open by design.

Author: novoj

jdwp-mcp-server/src/main/java/one/edee/mcp/jdwp/JDIConnectionService.java

@@ -947,7 +947,9 @@ Use jdwp_get_locals() to discover objects in the current scope.""",
 
             return result.toString();
         } catch (Exception e) {
-            return "Error: " + e.getMessage();
+            // Never surface the useless literal "Error: null": some JDI exceptions carry no detail
+            // message. Same fallback idiom this class already uses for connect() failures.
+            return "Error: " + (e.getMessage() != null ? e.getMessage() : e.getClass().getSimpleName());
         }
     }