Prevent Studio Code from overwriting manual editor changes with stale content

[sejas]

Related issues

• Related to STU-2048

How AI was used in this PR

Proposed Changes

When a user manually edits a page in the WordPress editor (for example, replacing placeholder images with real ones) and later asks Studio Code for a content-only tweak, the agent could push a stale locally saved copy of the page back over the live content, silently reverting the user's manual changes.

This happened because the agent's working copy of a page is a local scratch file (<site>/tmp/page-<slug>.html) that persists across turns and sessions, and applying content is a full post_content overwrite — nothing ever re-read the live content first. The live database row (where editor saves land) is the only copy of the user's manual edits.

This PR closes that gap at the instruction layer:

• The block-content skill gains a mandatory "Editing Existing Content" recipe: before any edit to an existing page/post, the agent must hydrate a fresh working copy from the live post_content (with a byte-count echo so an empty read from a wrong post ID is caught instead of applied), edit that fresh copy, and validate + apply in the same work burst. Stale scratch files from earlier tasks/sessions must never be the starting point.
• The system prompt's "Apply content" step and the native-PHP scratch-file guidance state the same read-before-write requirement.
• The wpcom-remote-management skill applies the equivalent rule to remote sites: fetch current raw content (context=edit) before updating, and treat staged payload files as single-use.
• The apply recipe now wraps wp_update_post in wp_slash() so editor-authored markup containing backslash escapes (common in block-attribute JSON) survives the hydrate → apply round trip instead of being corrupted.

User impact: manual editor changes survive subsequent Studio Code content edits, on both local sites (Playground and native PHP runtimes) and connected WordPress.com sites.

This is a prompt/skill-level fix. A deterministic tool-level guard (compare-and-swap on apply, blocking blind post_content overwrites in wp_cli) is planned as a follow-up.

Testing Instructions

Unit tests: npm test -- apps/cli/ai/tests (new skills-content.test.ts plus new assertions in system-prompt.test.ts pin the load-bearing wording).

Agent eval: npm run eval -- --filter-pattern "hydrates from live content" — new stale-content-hydration case reproduces the bug end-to-end: an out-of-band image swap must survive a subsequent heading-only edit, and the agent must re-read live content before applying.

Manual repro:

1. In Studio, ask Studio Code to build a page (it will use placeholder images).
2. Open wp-admin, edit that page in the block editor, replace a placeholder image with a real media-library image, and save.
3. Ask Studio Code for a small content-only tweak on the page (e.g. "change the hero heading text").
4. Verify the transcript shows the hydration step (hydrated N bytes) before the edit, and the real image survives alongside the new heading.
5. Repeat with a Studio restart between steps 2 and 3 (stale scratch file persists on disk) and on both Playground and native PHP runtimes.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?