Fix nested code fence parsing in lists

[nathan-contino]

I noticed that YAML code fences in lists don't get proper parsing. Here's a fix.

The test uses a truncated version of the actual file where I noticed the problem in my employer's docs.

[dacharyc]

Hey Nate - thanks for the PR, it's good to see your name and avatar pop up 😁

Good catch on the bug here, and your fixture reproduced the right scenario, but I've pushed a follow-up commit to your branch (edc0662) that adjusts two things:

1. The regex needed a different indent strategy. ^ {0,3} can't match fences inside list items, because they're indented by the list marker width (4 spaces for Turndown's 1. item style), so the new pattern never matched the case in your test fixture. The pushed version captures the opener's indentation (^( *)) and requires the closer at the same indent plus CommonMark's 0-3 slack, which handles any marker width while keeping a deeper-indented literal ``` inside the block from closing it early.

2. The test fixture was one segment short of being exercised. The check auto-passes pages with fewer than 10 unique segments of 20+ chars (MIN_SEGMENTS_FOR_COMPARISON), and the truncated fixture produced exactly 9, so the test passed on main even without the fix. I added one paragraph to each side so it now fails without the regex change and passes with it.

I also reverted the package-lock.json changes since they were unrelated to the fix (a different npm version rewriting peer entries).

I appreciate you taking the time to make the PR, and it's cool that you're using afdocs and finding it useful enough to contribute! We should catch up sometime and compare notes. 😀