ci: escape regex metacharacters in baseline links for .lycheeignore

[DatanoiseTV]

Description

The pr-check-links workers append the baseline link dump verbatim to .lycheeignore, whose lines lychee parses as regexes. Any baseline URL containing regex metacharacters aborts the whole check with a parse error before a single link is verified.

This is live on main today: the provisioning QR-code URL in content/blog/2026/05/simple-provisioning/ (qrcode.html?data={%22ver%22...}) contains {...}, which lychee rejects as an invalid repetition quantifier:

Error: regex parse error:
    https://espressif.github.io/esp-jumpstart/qrcode.html?data={%22ver%22,...}
error: repetition quantifier expects a valid decimal

As a result, every PR whose diff touches the blog_0-9a-f bucket currently fails check-links regardless of its own links (seen on #742, where blog_0-9a-f fails and blog_g-z passes).

The fix escapes regex metacharacters in the baseline dump before appending, so baseline URLs match literally.

Related

• Observed on Add blog post: Rust smoltcp as an alternative TCP/IP stack for ESP-IDF #742

Testing

Verified the sed transform on the offending URL:

$ echo 'https://espressif.github.io/esp-jumpstart/qrcode.html?data={%22ver%22:%22v1%22}' | sed 's/[][\.^$*+?(){}|]/\\&/g'
https://espressif\.github\.io/esp-jumpstart/qrcode\.html\?data=\{%22ver%22:%22v1%22\}

which is a valid regex matching the URL literally.

[pedrominatel]

@f-hollow, PTAL.

[f-hollow]

@DatanoiseTV

I tested your changes. Now the issue of broken links reported from non-PR changes is gone!

Thank you very much for digging into it!

LGTM!