* auto create mode for report cmd

* Fix "[object Response]" error in --auto-create report flow (TCV-6489)

Two issues fixed:
1. The SDK's getTestCases was called with a _filter param containing
   {suite: id}, but the testcases API doesn't support _filter, causing
   a 500. Replaced with a direct fetch using the suite query parameter.
2. The outer catch block didn't handle raw Response objects thrown by the
   SDK on non-2xx status codes, resulting in unhelpful "[object Response]"
   error messages. Now extracts HTTP status and response body.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* Preserve nested suite hierarchy in --auto-create (TCV-6492)

The --auto-create flow was flattening Mochawesome's nested suite
structure: every suite was created at the project root with
parentId: 0, losing the parent/child relationships from the report.

Track each test's full suite path during parsing (suitePath: array of
ancestor titles from root to leaf), then in autoCreateTestPlan walk
every unique path prefix, parents first, creating each level with the
correct parentId. Matching against existing suites now requires both
title and parentId so two suites with the same name under different
parents are treated as distinct.

Tests assigned to intermediate suites (e.g. directly under MCP, not
only under MCP > Claude) are routed to the correct non-leaf suite.

* Preserve nested testsuite hierarchy for JUnit reports too (TCV-6492)

JUnit XML can use nested <testsuite> elements (one suite wrapping
another) to express a test hierarchy. The previous parser walked
testcases with a flat regex and used `classname` as the suite, so
nested reports collapsed into one synthetic flat suite per classname.

parseJUnitXml now walks the document in order, tracks the open
<testsuite> stack, and records each testcase with its ancestor
snapshot. After scanning, if any nesting depth >= 2 was seen, every
testcase uses its ancestor stack as the suitePath (because nested
JUnit emitters typically put the full ancestor chain into classname,
making it unusable as a suite name). For flat single-level documents,
the legacy classname-based behavior is preserved unchanged so
existing reports keep working.

Tests sitting directly under an intermediate testsuite (e.g. under
"MCP Platform" rather than under "MCP Platform > Server Lifecycle >
Boot Validation") are routed to that intermediate suite — not to a
synthetic suite named after their path-prefixed classname.