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.

      *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

Start in blocks.c at parse_code_block_prefix and inspect how S_advance_offset uses parser->offset relative to parser->first_nonspace. Reproduce the case with an indented closing fence and run the existing cmark test suite; done means the parser offset ends at the consumed fence without regressing other fenced-block cases.