fix(polylang): repair single-post machine translation

[oxyc]

Problem

gds/translations-machine failed on the single-post path while the bulk string path worked fine. Two separate bugs in MachineTranslateAbility::translatePost():

1. Blocks::__construct(): Argument #1 ($id) must be of type int, null given
PLL_Export_Data_From_Posts::send_to_export() expects WP_Post[], but we passed [$postId] (an int). Inside Polylang Pro the int reaches the ACF block dispatcher as new Blocks($post->ID) — ->ID on an int is null, so it throws a TypeError.

2. Call to undefined function get_default_post_to_edit()
   Polylang's save path calls get_default_post_to_edit(), which lives in wp-admin/includes/post.php and isn't loaded in the REST/MCP/CLI context this ability runs in.

Fix

1. Pass the $post WP_Post object we already fetched, instead of the int ID.
2. Guarded require_once ABSPATH.'wp-admin/includes/post.php' — the same pattern already used in ManageRevisionsAbility and MediaUploadAbility.

Tests

Adds test_machine_translate_export_accepts_post_object, which drives the same export path the ability uses with a block post. It reproduces bug 1 without needing DeepL. It skips when Polylang Pro is absent (e.g. wp-env's free Polylang) and runs under DDEV where Pro is installed.

Verification

Confirmed end-to-end against real DeepL:

Path	Result
New translation (EN page w/ ACF blocks → FI)	✅ created
Re-translate existing target (overwrite branch)	✅ updated in place, no duplicate
Different target language (SV)	✅ created
Custom post type with ACF meta (Case → FI)	✅ created (other dispatcher hook)
Undo / revert	✅ clean restore

🤖 Generated with Claude Code