Incorrect `parser->offset` advancement for closing fenced code blocks in `parse_code_block_prefix`

## Description In the `parse_code_block_prefix` function within `blocks.c`, when a closing fenced code block is successfully matched, the `parser->offset` is advanced by the length of the fence sequence (`matched`) using `S_advance_offset`. However, `S_advance_offset` advances `parser->offset` *from its current value*, which is not necessarily aligned with the start of the fence. ```c *should_continue = false; S_advance_offset(parser, input, matched, false); // <-- This line parser->current = finalize(parser, container); ``` `S_advance_offset` is called with `matched` as the `count`. If `parser->offset` is, for example, `0` (start of the line) and the fence starts at `parser->first_nonspace` (e.g., `4` due to indentation), then `S_advance_offset(parser, input, matched, false)` would advance `parser->offset` from `0` by `matched` bytes, instead of advancing it from `parser->first_nonspace` by `matched` bytes. This leaves `parser->offset` at an incorrect position relative to the end of the consumed fence. ## Environment * **cmark version:** 0.31.1 * **Platform:** Windows * **Compiler:** Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30154 for x64