Fix nested fenced code block handling in typewriter output

The ResponseHandler::handle method in jp_cli::cmd::query contains logic
for adjusting typewriter "typing speed" based on whether content is inside
a markdown fenced code block or not. However, this logic does not properly
handle nested fenced code blocks.

The issue stems from the in_fenced_code_block boolean field in
ResponseHandler, which tracks code block state using a simple true/false
flag. When processing a LineVariant::FencedCodeBlockEnd, the handler
always sets self.in_fenced_code_block = false, regardless of whether
there might be parent code blocks still open.

This causes the typewriter to incorrectly revert to the non-code-block
typing speed (text_delay instead of code_delay) when it encounters the
closing fence of a nested code block, even though the content is still
within a parent code block.

Current problematic behavior:

LineVariant::FencedCodeBlockEnd { indent } => {
    // ... other logic ...
    self.in_fenced_code_block = false;  // Always resets to false
    // ... rest of method ...
}

Example content that demonstrates the bug:

This is normal text.

```markdown
This is in a code block.

```rust
fn main() {
    println!("This is nested code!");
}
```

This should still be in the markdown code block, but will use text_delay.
```

Back to normal text.

The nested Rust code block closes and incorrectly resets the handler state,
causing the remaining markdown content to be typed at the wrong speed.

Expected behavior:
The handler should maintain a nesting counter or stack to properly track
multiple levels of code blocks, only reverting to text_delay when all
code blocks have been closed.

Location:

• File: crates/jp_cli/src/cmd/query.rs
• Struct: ResponseHandler
• Method: handle_line (around line 1090)

Start in crates/jp_cli/src/cmd/query.rs at ResponseHandler::handle_line, around line 1090, and inspect how FencedCodeBlockStart and FencedCodeBlockEnd update in_fenced_code_block. Verify the nested Markdown/Rust example, and consider the issue's expected completion condition: code_delay remains active until all nested fences are closed, then returns to text_delay.