Use correct wp_kses arguments in inline-save error paths

[GaryJones]

Summary

Three inline-save AJAX handlers — for custom statuses, editorial metadata terms and user groups — built their "could not update" error message with sprintf and then ran it through wp_kses() with the wrong second argument. Two of them passed the string 'strong', which wp_kses_allowed_html() does not recognise as a context and so silently collapses to the small default inline-tag allowlist. The third passed nothing at all, which produces a TypeError on PHP 8 because $allowed_html is a required parameter; reaching the error branch on a modern install thus turns a benign "term could not be updated" path into a fatal.

Each site now passes an explicit array( 'strong' => array() ) so only the intended bold wrapper survives kses, and the user-supplied term name interpolated into the message is first run through esc_html(). The belt-and-braces shape matches the other wp_die() error paths in the same handlers — even if a translation file is ever tampered with, the inserted name cannot break out of the wrapper.

No behaviour change on a happy path: the message still renders the same for the administrator who hits it. The PHP 8 fatal is the only user-visible difference, and that was already latent in editorial-metadata.php before this PR.

Test plan

• composer test:integration — existing tests continue to pass
• On PHP 8, force the error branch in handle_ajax_inline_save_term (e.g. by temporarily making update_editorial_metadata_term return a WP_Error); confirm the response is a formatted error rather than a TypeError