Report unset() of an offset on a union with a scalar member

[SanderMuller]

unset($x['k']) deprecates when $x is false (since PHP 8.1) and throws an Error when $x is true, an int, a float or a string. UnsetRule reported this only when the offset can never be accessed, so a union like array|false, array|int or array|string went unreported:

function foo(string $url): void {
	$parsed = parse_url($url);
	unset($parsed['port']); // new: Cannot unset offset 'port' on array{...}|false.
}

This PR reports a union with a scalar member as well:

• Only with reportMaybes, so from level 7, the same as NonexistentOffsetInArrayDimFetchRule reports offset reads.
• Behind a new bleeding edge toggle, unsetOffsetOnMaybeAccessible.
• mixed is not reported, because it is only maybe a scalar. The test covers a json_decode() result after isset().
• A type whose offset access is not even legal (an object without ArrayAccess) is left out. NonexistentOffsetInArrayDimFetchRule already reports it inside unset(), so it would be reported twice.
• array|null is not reported, because unset() on null does nothing.

The first version of this PR used RuleLevelHelper::findTypeToCheck(), and mutation testing showed that its union filter callback could not be tested here. Checking for a scalar member is simpler, and it also covers array|string.

On WordPress trunk from 2026-10-07 at level 8, the toggle adds one error: unset( $redirect['port'] ) on a parse_url() result in redirect_canonical().

The shopware/shopware integration job reports one new error, and I think it is correct. ImportExportProfileApiTest.php:85 does $entry = current(...), which is array|false, and then unset($entry[$property]). Shopware enables bleeding edge, so the check runs there. It needs an entry in shopware-baseline.neon in phpstan/phpstan.

This is the follow-up I mentioned in #6722, which keeps the type of the variable after such an unset(). The two PRs do not depend on each other.

🤖 Generated with Claude Code