investigate tool returns null taskId/executionId — flattens response with wrong key path

## What happened

Calling the convenience `investigate` MCP tool always returns a "started" response with `taskId` and `executionId` set to `null`, even though the investigation was actually created successfully on the backend.

## Root cause

`investigate`'s response handling flattens the backlog-task payload with `parsed.get("taskId")`, but the real field lives one level deeper, at `parsed["task"]["taskId"]`. Since the top-level key doesn't exist, `.get()` silently returns `None` instead of raising — so the bug is easy to miss unless you check the actual investigation status separately and notice it doesn't match the `null` IDs you were handed back.

## Confirmed behavior

Verified 2026-08-23 against a live instance (creating a deliberately-broken Lambda + CloudWatch alarm to trigger a real investigation):

- `investigate` → `taskId: null`, `executionId: null`
- `create_investigation` (called directly, same underlying backlog-task shape, not flattened) → `task.taskId` and `task.executionId` populated correctly

## Workaround

Skip `investigate` and call `create_investigation` directly, reading IDs from the nested `task` object instead of the top level.

## Suggested fix

Fix the flattening in `investigate`'s response handling to read `parsed["task"]["taskId"]` / `parsed["task"]["executionId"]` (matching what `create_investigation`/`get_task` already return correctly).

## Context

Found while integrating this MCP server into an external client ([victoria-gateway](https://github.com/GordonWei/victoria-gateway)), where the workaround above is what's currently implemented.

Start with the response handling for the `investigate` MCP tool and compare its flattening with the nested payload returned by `create_investigation` and `get_task`. Done means `investigate` returns populated `taskId` and `executionId` values matching the backend investigation, rather than null.

Written by the indexing model from the issue text.