feat: add WordPress 6.9 and 7.0 upgrade rule sets

[abhishek-kaushik]

Summary

Adds upgrade rule sets for WordPress 6.9 and WordPress 7.0, extending the package's coverage from 0.71–6.8 to 0.71–7.0.

Every deprecation below was verified directly against WordPress core at the 6.9 and 7.0 tags of wordpress-develop (the _deprecated_function() call and its named replacement), not inferred — see Verification below.

New constants:

• WordPressSetList::WP_6_9, WordPressSetList::WP_7_0
• WordPressLevelSetList::UP_TO_WP_6_9, WordPressLevelSetList::UP_TO_WP_7_0

Deprecations covered

Simple renames (RenameFunctionRector)

Version	Deprecated	Replacement
6.9	seems_utf8()	wp_is_valid_utf8()
6.9	wp_print_auto_sizes_contain_css_fix()	wp_enqueue_img_auto_sizes_contain_css_fix()
7.0	addslashes_gpc()	wp_slash()
7.0	block_core_navigation_submenu_render_submenu_icon()	block_core_shared_navigation_render_submenu_icon()

Rename + added arguments (new RenameFunctionWithArgumentsRector)

Some replacements are not drop-in renames — they require additional arguments:

Version	Before	After
6.9	utf8_encode($x)	mb_convert_encoding($x, 'UTF-8', 'ISO-8859-1')
6.9	utf8_decode($x)	mb_convert_encoding($x, 'ISO-8859-1', 'UTF-8')
7.0	block_core_navigation_block_contains_core_navigation($blocks)	block_core_navigation_block_tree_has_block_type($blocks, 'core/navigation')

New rule: RenameFunctionWithArgumentsRector

The cases above rename a function and append arguments. This has to happen in a single pass. Chaining the core RenameFunctionRector (rename) with ParameterAdderRector (add args) would be unsafe: once utf8_encode is renamed to mb_convert_encoding, the arg-adder can no longer distinguish the migrated call from a pre-existing mb_convert_encoding() call already in the user's code, and would wrongly append arguments to the latter. This is the same rule-ordering hazard documented in config/config.php.

The new rule matches the old function name, renames it, and appends configured literal arguments atomically — so it never touches pre-existing calls to the target function, and it is idempotent (re-running finds nothing to match). It is registered in the config/config.php preload alongside the other custom rules, following the existing convention.

Intentionally left as TODO

• wp_sanitize_script_attributes() (7.0) — no safe automatic transform. It returns a string of HTML attributes, whereas its suggested replacements wp_get_script_tag() / wp_get_inline_script_tag() return a complete <script> tag and take different arguments. A mechanical rename would emit broken markup, so this needs manual migration. Documented in config/sets/wp-7.0.php.
• _wp_can_use_pcre_u() (6.9) — its unused $set argument was dropped, but the function is private/internal (@access private) and unlikely to appear in plugin/theme code. Documented in config/sets/wp-6.9.php.

Tests

• Per-version set tests: Wp69, Wp70
• Cumulative level test: UpToWp70 (exercises the full 0.71 → 7.0 chain, extending the existing UpToWp68 fixture)
• Rule test for RenameFunctionWithArgumentsRector

All existing checks pass locally (matching CI): PHPUnit (66 tests), Pint (PSR-12), PHPStan (level max, no errors), Rector dry-run, composer validate, composer normalize.

Verification

Deprecations were confirmed against:

• wordpress-develop at tags 6.9 and 7.0 — wp-includes/deprecated.php, wp-includes/compat.php, wp-includes/formatting.php, wp-includes/blocks/navigation.php, wp-includes/blocks/navigation-submenu.php
• The WordPress 6.9 Field Guide
• developer.wordpress.org reference pages for the individual functions

No deprecations were found in wp-admin/includes/deprecated.php, pluggable-deprecated.php, or ms-deprecated.php for either version.

[fsylum]

@abhishek-kaushik I'd like to keep it focused on WP-specific function. Can we remove this one? If we remove this then we don't need FunctionRenameWithArguments I think?