Slash page content before writing in import-page-draft

[jasperf]

import-page-draft still carries the defect that was fixed for publish-post in v5.16.1 (#210, also shipped in the current v5.17.0). This PR lands as 5.17.1.

Both the local and the production path passed file_get_contents() straight into wp_update_post(), which calls wp_unslash() internally and expects slashed input. Every literal backslash was eaten on the way into the database.

Prose is unaffected, which is why it goes unnoticed. A page draft carrying code is silently corrupted: \", \', \\, \n, \b and backreferences like \2 are load-bearing in regexes and printf/sprintf calls, and simply vanish.

How this surfaced

Hit today on a live post (13729) via the publish_post MCP tool. The v5.16.1 fix was already merged and built, but mcp-server/run.sh rebuilds only at process start, so a long-running MCP session kept executing the pre-fix build while the corrected dist/ sat on disk. The stored PHP sample came back as:

• \bct-inner-content\b -> bct-inner-contentb
• str_replace( '\\', '\\\\', $notice ) -> str_replace( '\', '\\', $notice )
• \n -> n, \2 -> 2

The regex a reader copies out of the published post is broken. Auditing the rest of the tree for the same pattern turned up import-page-draft.sh as the one remaining unslashed write.

Change

Wraps the body in wp_slash() on both the local and production paths, matching how publish-post.sh does it, with a comment explaining why. bash -n clean.