Backslashes are stripped from snippet content when pulling from a GitHub-synced repo.

Concrete example from my own snippet:

• Before (GitHub source): $routes = ["/wp/v2/users", "/wp/v2/users/(?P<id>[\d]+)"];

• After (pulled into SnipVault / deployed): $routes = ["/wp/v2/users", "/wp/v2/users/(?P<id>[d]+)"];

The \d became d — the backslash was silently dropped, breaking the regex.

Steps to reproduce:

1. Push a snippet containing a literal backslash (e.g. a regex like \d) to the linked GitHub repo.

2. Pull that snippet into SnipVault.

3. Compare: the GitHub source still has \d, but the pulled/deployed snippet now has d — the backslash is gone.

Impact: Any snippet content containing backslash escapes (regex patterns, \n, Windows paths, etc.) is silently corrupted on pull, with no error or warning. In my case this broke a regex-based permission check that was meant to restrict access to a REST API endpoint — it deployed "successfully" but the protection silently didn't work, and there was no indication anything was wrong.

Suspected cause: Looks like stripslashes() (or wp_unslash()) is being applied somewhere in the GitHub pull path — its documented behavior is exactly this: \d → d, backslash dropped whenever it precedes a character with no special meaning.

Thank you.